aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Blocking while waiting for record lock to clear Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Blocking while waiting for record lock to clear" Watch "Blocking while waiting for record lock to clear" New topic
Author

Blocking while waiting for record lock to clear

Douglas Kent
Ranch Hand

Joined: Oct 06, 2000
Posts: 171
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

Joined: Jan 08, 2001
Posts: 6
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

Joined: Dec 07, 2000
Posts: 133
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

Joined: Oct 06, 2000
Posts: 171
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

Joined: Nov 02, 2000
Posts: 18
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

Joined: Jan 08, 2001
Posts: 6
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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Blocking while waiting for record lock to clear