Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: lock, update, unlock scenario

 
joe black
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lets say that multiple concurrent threads are trying to update a certain record, but one of them uses the wrong cookie and throws a SecurityException. Won't this result in a deadlock since the other threads will be waiting to lock that same record, but it will never get unlocked since the SecurityException was thrown?
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Won't this result in a deadlock since the other threads will be waiting to lock that same record, but it will never get unlocked since the SecurityException was thrown?
Not if that exception is propagated up the call stack into the try-catch followed by the finally block where you would unlock that record.
 
joe black
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But my unlock() also requires the cookie value to unlock, so that could be the same invalid cookie, and the SecurityException would be thrown again.
 
Jay Bromley
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Joe,
I believe you are correct, a thread getting a SecurityException could cause a deadlock. However, I also think that this case should never happen unless you've got a programming bug or the JVM gets hosed during execution.
Consider a basic book function (I leave out exception handling intentionally here):

With code like this, assuming lock works correctly, how could an incorrect cookie ever occur unless something was seriously wrong? The cookie is method -local and so how could anyone else change it? So, the way I see it, this "security model" is kind of bogus for an app with a book method like above. Yes, if the cookie is corrupted this could cause problems, but if your JVM is hosed then I would think all bets are off for any running classes.
One note, my thinking is based around book/find methods provided by a service layer that is called (possibly over a net via RMI) by clients, though I think the same is true if the client itself does the book sequence.
Regards,
Jay
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12007
215
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Joe,
As Jay says, there is no reason why in normal processing you should be unable to unlock a record you locked.
It is possible that if your client application crashed then your cookie would be lost, and you would be unable to unlock the cookie.
To solve this issue, you could look at using the Unreferenced interface to get notification if a client crashes / disconnects while still owning a lock.
It is also possible to use a WeakHashMap (or some other WeakReference) to maintain the locks, but I believe the logic for that is non trivial when dealing with cookies, so I would not recommend it for you.
Cleaning up after a client disconnects is possibly outside of scope for this assignment, but many of us believe that a professional solution will consider it.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic