I currently cache all records at start up into a Database object, which contains a set of Record objects.
Now I am looking at locking and from what I can tell a lot of people seem to be synchronizing on a Collection of some sort to store the lock cookies. Which means that all threads get notified when a thread has finished locking a record rather than just the ones that can now lock the record they want.
I was thinking of using a different approach and putting the lock on my Record objects that are already there. This would mean a thread would only be waiting on the object it is trying to lock and therefore a notifyAll will only affect the threads that are trying to lock this record. The record would then store the lock cookie.
Does that make sense? What do people think of this idea? Too complex? Or have I already made the solution too complex by caching the records?
for clarity my lock and unlock signatures are:
Thanks for your input
Neil Renaud<br /> <br />SCJP 1.4<br />SCWCD 1.4<br />SCJD - In progress since March 05
Hey guys, I've been implementing the same idea... i think it makes a more efficient design without adding any complexity. However, there's a little problem I've encountered, what happens here:
lock(recNo); erase(recNo); unlock(recNo);
If you erase the same record instance that contains locking information (like the owner or the cookie), then the unlock() method will throw a RecordNotFoundException right? I believe this is also a problem if you implement the collection approach, but it gets more hostil in ours. Have you wondered what happens if a client is in the wait() state to acquiere a lock that has been erased and for instance the original owner of the lock won't be able to call to notifyall() ?? Any thoughts?
By the way, my lock signature is
[ July 11, 2005: Message edited by: Alex Matute ]
-------------------<br /> <br />SCJD
Joined: Dec 29, 2004
I solved this by choosing that it is legal (even compulsory) to unlock a record after it has been deleted. I will only throw RecordNotFoundException from unlock when a client attempts to unlock a record that it did not lock.
ALternatively, you could call notifyAll from the delete method, but I dislike the lack of symmetry of that solution.
Joined: Jun 28, 2005
Thnx Frank, I believe that fixes my bug, although I throw a SecurityException instead of a RecordNotFoundException when the record is not locked or this client is not the owner of the lock. I do that to be persistent with my design (I throw SecurityExceptions when a Client tries to read/update/delete/update/unlock without having the lock).
Have a nice day!
Joined: Dec 29, 2004
I agree wholeheartedly that SecurityException would be more appropriate, but sadly my interface did not define any SecurityExceptions.