NX: lock, update, unlock scenario

[joe black]

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]

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]

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]

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):

...
cookie = lock(recordNum);
update(contractor, cookie);
unlock(recordNum, cookie);
...

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]

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