Hi Dinesh,
Michael is correct - you do not
have to do locking for FBNS in single user mode.
However I decided to do it. My convoluted logic is:
If my client does not call lock explicitly, then I will have to do it behind the scenes: whenever they call modify in my client connection factory object, the connection factory object will have to call the remote lock, modify, and unlock methods. So far so good.
But, according to our instructions, we have to expose the lock and unlock methods to the remote client. Therefore someone could be enhancing my code, and notice that my code does not call the lock method. (the locking is done in the connection factory object, the implementation of which is hidden from the client code). So the other programmer adds a call to lock in the client code.
Now what happens? Does the connection factory have to handle the case where a record is allready locked? How does it know? If it tries to get the lock a second time, what happens? Should the server ignore the request since the client already owns the lock? I dont think so - a logic flaw in client code could result in one client doing two simultaneous updates which would be treated as one update in this case. Should the server attempt to get the lock again - in which case deadlock will occur. Should the server give a deadlock exception? This has gotten ugly real fast.
Also, I believe locking should be in the client code. Consider a potential future requiement where we need to be able to book two flights simultaneously. If we dont get both we dont want either. The example I like to give is from when I lived in Holland, but used to travel back to Australia every year. There was only one flight from Holland to London that I could catch in the morning (and it required me to be up at 4am
) in order for me to catch the
only morning flight from London to Sydney. If I could not book the Holland flight, then the London flight was no good. If I could not catch the London flight, then the Holland flight would get me into London 12 hours before the next Australia flight - also not wanted. The best way to handle this is to lock both flights, confirm availability on both flights, book both flights, unlock both flights. Otherwise you would need some way of backing bookings out.
OK - I admit that both examples are not in the requirements.
However I think the first example falls into the category of making the code simple enough for a junior programmer to understand. I would not want the junior programmer to break the code because they thought I had missed something.
And I think the second example falls into the category that the code must be extensible.
Regards, Andrew