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 of all records in db.db

 
Bhamidi Krishna
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I am trying to appear for the SCJD Exam and have a question about locking all records. How I implement it is :
check for availability of records
as the records become available, lock them
If all records are locked, return to the user (GUI)
Any better way of implementing it?
Thankyou,
BK
 
Rick Fortier
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bhamidi Krishna:
Hi,
I am trying to appear for the SCJD Exam and have a question about locking all records. How I implement it is :
check for availability of records
as the records become available, lock them
If all records are locked, return to the user (GUI)
Any better way of implementing it?
Thankyou,
BK


I would not lock records individually.
I think that since there is no requirements on how to do this you will have to decide which method to use. Then you will need to justify which method in writing.
The choices would be:
1. Issue the lock immediately. (In which case you could deny anyone else new locks but allow others to finish their task)
2. Wait for all users to release their locks before locking.
In MS SQL Server, they have a single user mode which you can switch to for special operations. All users must already be disconnected in order to enter that mode.
Just my $.02.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem with progressively locking records as they become available is that it invites deadlocks (not in the Fly By Night application, but in general).
Say, there is a client A which needs to lock record 12 and 14 for some reason. The API does not allow you to lock both simultaneously. Suppose that, between acquiring lock 12 and attempting to acquire lock 14, client B tried to grab a table lock. Then client A will hold 12 and be waiting for 14, client B will be waiting for 12 and have locks on everything else. Deadlock!
For this reason, I implemented the table lock to wait until all locks had cleared. The disadvantage of that is that it may take a long time to acquire a table lock, but to my mind that is more acceptable than a deadlock-prone solution.
Of course, you could handle deadlocks using timeouts, but then it gets overly complicated for the purpose.
- Peter
 
Rick Fortier
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't understand what would cause a deadlock.
My choice on this is to place -1 in my array of locks, and allow all existing locks to continue their operation until complete. In other words, allow unlock() to be called, but once -1 is in my array of locks, noone else may lock. And so all other people trying to get a normal lock are blocked.
The instruction is "The lock method should block until the requested lock can be applied." So when -1 exists in my array, all other lock attempts will block until -1 gets unlocked.
Do you think this is what is required? Or would it be better to through an exception stating "The Database is locked". The signature of lock() does not throw any exceptions.
I have implemented a TimerTask object to periodically clean up any locks which are stale. But my intentions for this was to clean up after any clients which died unexpectedly without calling unlock, not to handle deadlock situations.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Rick Fortier:
[...] And so all other people trying to get a normal lock are blocked.

The problem is that a client trying to get the second of two locks (surely not an obscure thing in the database world) is blocked as well. And because it is blocked, it will never release its first lock. Eventually you will time it out, which will resolve the deadlock, at the price of causing trouble for a perfectly legally behaving client.
- Peter
 
Rajesh Matti
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter -
You wrote
=============================================
Say, there is a client A which needs to lock record 12 and 14 for some reason. The API does not allow you to lock both simultaneously. Suppose that, between acquiring lock 12 and attempting to acquire lock 14, client B tried to grab a table lock. Then client A will hold 12 and be waiting for 14, client B will be waiting for 12 and have locks on everything else. Deadlock!
For this reason, I implemented the table lock to wait until all locks had cleared. The disadvantage of that is that it may take a long time to acquire a table lock, but to my mind that is more acceptable than a deadlock-prone solution.
=================================================

The above example is also true underthe following example too.

Client A wants to lock record 10 and 15.
Client B wants to lock record 15 and 10 (say reverse order).
Now, client A gets lock for 10.
Before client A gets back again for 15, say, B locks 15 and again try to lock 10 (which is already owned by A). Now, A comes back for locking #15 and he has to wait since B has already locked it. There is the dealock.
without a wait('n' milliseconds), or creating another thread for detecting deadlocks and doing unlocking behind the scenes) how did you overcome the problem ?.
Thanks,
-Rajesh
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Only have the client able to lock one record at a time, such that in a method you have the lock call and the unlock call.
Yes you might have a deadlock in that case if you don't unlock a record.
Besides this thread was back in June.
Mark
 
Rajesh Matti
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mark- Thanks for repling me.
Still, I did not understand the following sentence.
===============================================
Only have the client able to lock one record at a time, such that in a method you have the lock call and the unlock call.
===============================================
I strongly feel that the lock mechanism implemented by the server should never depend on the coding practices/conventions of the remote client unless otherwise server contracts metnions that client can have only one record lock. What if client wants to book more than one seat, is it whatever is avilablet or 'all or none' ?. Please verif.
BW, I do not know if it is okay to post a repl to an old thread, I just followed few example s set by others. Please clarif the too.
Thanks Mark,
-Rajesh
 
Bal Sharma
Ranch Hand
Posts: 273
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Rajesh:
I think it is OK to read, learn old posting. Activating old thread at least does not make sense to me. Because original authors may not reply our questions. We may not able to understand the 'SPRIT' why they started the thread. So, this is completely my personal opnion. To get fresh view better to start new thread.
Lock unlock are heart of this program. I have looked at different way then others. I did not even implemented it in Data class. My logic is if you do not need it why do you keep it. In RemoteData class you need it and implement it. Of course, I have to defend my choice. Right!
When I am running on remote mode if any client call seatBooking method they got to follow lock-read-modify-unlock sequence. If client is in local mode who cares how many seat or how many times client wannna use booking method. Because it only one client. 'NO ONE GONNA CHANGE' shared resources.
Hope it helps. -Bal
 
Rajesh Matti
Ranch Hand
Posts: 121
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bal - Thanks for replying me. However, unless otherwise the Data class says in its contract that lock (only one record), read, modify, unlock(the locked record) and throws an exception if same client tries to lock another record while owning a lock on one, I think that it is not a good idea to assume the client's coding practices. In addition, though lots of other people have different opinion, I see locking in the local mode also a requirement, because, client can always have mutilple threads running, example, he would have issued a command to do a new search, while continues updating in another window. Others may think this is an overkill, but, I feel that behaviour of the Data class should not change (corrput the data) when local client has multiple windows with multiple threads processing his/her request, keeping in mind the possible future enhancements (like MDI) (which is in fact a requirement by Sun).
Anyway,
More I think about it and read about it, more confused I get. I think I will make the above choice and justify it.
Thanks,
-Rajesh
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
 
Don't get me started about those stupid light bulbs.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic