• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Locking idea for URLYBird

 
Neil Renaud
Greenhorn
Posts: 15
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Frans Janssen
Ranch Hand
Posts: 357
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Alex Matute
Greenhorn
Posts: 14
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Frans Janssen
Ranch Hand
Posts: 357
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 357
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Alex,

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

Frans.
 
Alex Matute
Greenhorn
Posts: 14
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Neither did mine, but they are unchecked!!!

Have a nice week!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic