Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking in offline mode

 
dinesh pande
Ranch Hand
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is regarding the FBN assignment. Could some one please help me understand if locking feature is required if the user chooses the offline mode.
Thanks
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This is regarding the FBN assignment. Could some one please help me understand if locking feature is required if the user chooses the offline mode.
There is no need for locking in local mode since there is only one client that can change the database.
 
S. Ganapathy
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Morris,
I think we should implement locking functionality for standalone mode too in new assignment as in the db interface, they mentioned lockcookie in update/delete records.
Regards,
Ganapathy.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ganapathy,
It sounds like for the new assignment you have no choice - you will have to implement locking in standalone mode as well.
Regards, Andrew
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Correct - NX: Contractors (at least) does not leave any real choice in the matter. There's no way a single client could use the DB API to update or delete a record without first acquiring a lock. Dunno about NX: Hotels - does it also require lock cookies? Of course the original question here was about FBNA, which evidently does allow more flexibility. (Damn creative programmers must have been annoying Sun's graders.)
[ May 23, 2003: Message edited by: Jim Yingst ]
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, I believe locking should be in the client code.
I agree Andrew. I used a Builder Pattern to create both local and remote DataAccess objects. The local objects just had empty lock() and unlock() methods. The client was oblivious to whether it was in local or remote mode after startup. So the procedure for doBooking() was still, lock-read-modify-unlock in local mode, it's just that lock and unlock didn't do anything. Also by using the Builder Pattern any number of different DataAccess objects could easily be created thru the connection Factory. If later it was determined that a certain clients needed a modified locking scheme or read-only access or whatever it would be a trivial matter to create a new implementation.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic