aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Locking idea for URLYBird 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 "Locking idea for URLYBird" Watch "Locking idea for URLYBird" New topic
Author

Locking idea for URLYBird

Neil Renaud
Greenhorn

Joined: Jan 19, 2005
Posts: 15
Hi guys,

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


Neil Renaud<br /> <br />SCJP 1.4<br />SCWCD 1.4<br />SCJD - In progress since March 05
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
hi Neil,

I think that is a very sensible approach. I did the same and I think (contrary to your observations) that the majority of the people here do it somewhat like that.

People have passed by locking on the entire collection though, so it is a valid approach too.

Frans.


SCJP 1.4, SCJD
Alex Matute
Greenhorn

Joined: Jun 28, 2005
Posts: 14
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
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Alex,

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.

Frans.
Alex Matute
Greenhorn

Joined: Jun 28, 2005
Posts: 14
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!
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Hi Alex,

I agree wholeheartedly that SecurityException would be more appropriate, but sadly my interface did not define any SecurityExceptions.

Frans.
Alex Matute
Greenhorn

Joined: Jun 28, 2005
Posts: 14
Neither did mine, but they are unchecked!!!

Have a nice week!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Locking idea for URLYBird