This week's book giveaways are in the Refactoring and Agile forums.
We're giving away four copies each of Re-engineering Legacy Software and Docker in Action and have the authors on-line!
See this thread and this one for details.
Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Blocking while waiting for record lock to clear

 
Douglas Kent
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One thing I have not seen discussed here is how to achieve the required blocking if one client wishes to access a record that is currently blocked. A partial solution (and I plan on using RMI) might be to have the thread requesting the lock (currently held by another client) place a reference to itself in a FIFO queue of clients waiting a lock on that record, then sleep for a reasonable length of time, getting awakened when the lock comes free. Where I get stuck is how does the current record lock holder wake up the sleeping thread to notify it that the record is now available? thread.interrupt() does not have arguments, so one thread cannot use this to signal another to wake up.
One other question--is it reasonable to assume that in local mode the database will only have to deal with one and only one local client? Or should we assume that while the database may be local, it may be shared on a LAN? Ideas?
 
Rajesh Chandrasekaran
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The required blocking could be provided by using a
wait() method on the thread that requests the lock.
The thread waits in an infinite loop till the record is unlocked.
The lock releasing thread, changes the lock status and
will do a notifyAll() to let other threads lock.
-Rajesh.
 
Sam Wong
Ranch Hand
Posts: 133
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How about synchronizing on a specific object that may be responsible for writing to the db. Remember the rules dictate that only 1 write can occur at any one time. If you implement a queue or wait in an infinite loop, you're not using existing funcationality. I haven't gotten to this point in the project yet but this would be my first approach.
 
Douglas Kent
Ranch Hand
Posts: 171
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rajesh,
I think your approach mis-states the way "wait" works. Wait can only be called by a program in a synchronized block. It releases the lock on that object, allowing other threads that are blocked awaiting access to that object. For this to work, I believe that the object that has the lock would have to execute a synchronized code block that would have as a first item of business setting the lock flag. It would then execute the update, release the lock, then exit the synchronized code. Another thread that has been blocked awaiting access to the synchronized code would then be granted access, and set its lock, and so on. I think this will work, but with the synchonization providing the real locking mechanism, is there a need for some external (to the database) object that holds locks for each record?
 
Abhijeet Premkumar
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Doug,
I've implemented a hash-queue based locking system which grants locks to clients in the order the requests arrive...ie. the first client in the queue gets the lock and the others have to wait in line.
And...I have had to use an external object to synchronize on to provide this functionality. Just my opinion though....
Hope this helps.
With warm regards
Abhijeet

-------------------------------------------
Originally posted by Douglas Kent:
Rajesh,
I think your approach mis-states the way "wait" works. Wait can only be called by a program in a synchronized block. It releases the lock on that object, allowing other threads that are blocked awaiting access to that object. For this to work, I believe that the object that has the lock would have to execute a synchronized code block that would have as a first item of business setting the lock flag. It would then execute the update, release the lock, then exit the synchronized code. Another thread that has been blocked awaiting access to the synchronized code would then be granted access, and set its lock, and so on. I think this will work, but with the synchonization providing the real locking mechanism, is there a need for some external (to the database) object that holds locks for each record?

 
Rajesh Chandrasekaran
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A couple of clarifications regarding the previous post:
Doug is right about the wait() method:
1. I failed to state explicitly that the sequence of operations I
suggested to lock are being done from inside a synchronized method.
wait() has to be called within a synchronized code.
2. And instead of an infinite loop, a while loop with a condition will do the necessary blocking
Inside a synchoronized method :
while (condition)
wait()
This could be synchronized on the lock of any Object.
In my case, it will be the subclass of Data.
Thanks for the corrections.
-Rajesh.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic