• 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

NX: lock, update, unlock scenario

 
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
reply
    Bookmark Topic Watch Topic
  • New Topic