• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Record-level locking question

 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sorry for the numerous questions. Internet access is sparse here in Iraq, so my posts tend to be "batch-posted" when I get online.

I'm implementing database record-locking. I have a Map<Long, Long> where key=recNo, and value=cookie. If there's an entry in the Map for that recNo, then the record is locked. When I use the wait() and notifyAll() methods, I'm using them on the map itself. I don't see how I can do it elegantly on a record-by-record basis.

My assignment specifies that if a client needs to lock a record, and the record is already locked, then the thread needs to go to sleep. In fact, it states that the thread must be "consuming no CPU cycles until the desired resource becomes available". By locking on the Map and not per record, I may be violating this. However it says that it "should", and not "must", so I guess I'm sort of safe?

Is there a way to wait() on a record instead of on the whole Map?

Obviously, I can set up something to do this, but every solution I come up with seems overkill and kludgey (like maintaining a HashSet or array of arbitrary objects to lock on). Locking on the Long objects seems a little flimsy. I like my simple Map<Long, Long>. Any ideas?
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
From my understanding, there is no need to wait() on an individual record.
You can just do it like this:




This works because the wait() is in a while loop. If a thread encounters an already locked record, it goes into waiting state, releasing the lock. If another thread unlocks a record, all waiting threads get woken up. Now, each one of them checks if it was the record they are interested in, that was unlocked. If a thread was waiting on the unlocked record, then it can proceed with the locking business, otherwise it goes to sleep again. If I'm not completely mistaken, there should be no potential deadlocks here, as there is a corresponding call to unlock() for each locked record.
What do you think?

Greetings,
alex
[ April 19, 2008: Message edited by: Alexander D�nisch ]
 
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have also taken into account the possibility that the current thread is actually the owner of the record lock, just in case there are nested lock requests. In this case, I do not make the thread wait, because it already owns the lock.
 
Alexander Duenisch
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sure, it's the same with me. The wait() loop is actually nested in an if-clause, that checks for lock ownership. If the current thread owns the lock, then the wait() will be skipped. I just didn't post the full code for the sake of simplicity.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic