• 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

B&S - Locking - Deadlock Situation

 
Ranch Hand
Posts: 456
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello everyone,

I'm reading in this thread since quite a while, and I have an issue which I do not find really covered in here:

Hello everyone,

I'm reading in this forum thread since quite a while, and I have an issue on the B&S assigment which I do not find really covered in here:

Situation - Client A needs a lock an Record 1:



So far so good.

But what if a unlock() got lost, and Client A already holds the lock to Record 1? Obviously, it would wait forever. Or till Germany wins the soccer world cup, which is equivalent.

If I'd be in the sun certification team, a testLockLock() class would be one of the first to write... ;-)

Facing this situation, I decided to implement a watchdog thread, which checks all locks in the datastructure, if they expired their time-to-live (which will be configurable), they get killed. Well, I don't feel that this is the most elegant way. For example the watchdog - if killing a lock - has to reset the cookie value in a Record object . This feels strange to me, record objects are three levels down the class diagramm

How did you guys approach this issue?

Greetings from Berlin,
jan
 
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

How did you guys approach this issue?



Hi Jan,

I solved this issue by replacing "is locked" with "is locked by a client other than myself".

Frans.
 
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hallo Jan,

I recommend you to enable that your client can book only one record at the same time:

Your client locks the recordA. If your client tries to lock the same or another record and your recordA is still locked give user the message, that the second record cannot be locked and cancel the second booking.

Viele Gruesse,
Olena
 
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 Jan,

First and foremost, I should state that I believe you do not need to handle the cases where clients disconnect without releasing their locks. I have seen many candidates pass with good scores without worrying about this. (Disclaimer: I did handle this situation in my own submission).

Frans has a good suggestion for the case where client A already owns the lock. However allowing clients to lock more than one record can still result in deadlock. Searching on the word deadlock should bring up some simple solutions, including only allowing clients to lock records in numerical order (that is, client A cannot lock records 3, 5, and 4 in that order) - in which case deadlock detection can be done easily. Phil Maquet also described a recursive lock check which went further - it handled the cases where any number of clients could be locking any number of records in any order, and he could detect deadlocks.

Regarding a client disconnecting / crashing without releasing a lock (unlock() getting lost) - this is possibly one of the most discussed topics in this forum .

Personally I don't like your suggestion of killing any locks that have been hanging around too long. The way I read the Sun assignments, once I have been given a lock, it is mine for as long as I want. There is nothing to suggest that it might be taken from me if I take too long. I personally feel that implementing a timeout on locks is not implementing the provided interface - it is implementing a solution that is just easier for me to handle.

If you are using RMI, you could look at the Unreferenced interface - this will give you notification that a client has disconnected. If you are using Sockets you will receive an Exception when the client disconnects. In either case, you will have an opportunity to clean up orphaned locks.

Alternatively you can look at using a WeakHashMap to store your locks. When there is no longer a reference to the lock (the client has disconnected) the lock will be automatically removed from the WeakHashMap.

If you have questions about any of these, please ask them. Otherwise, possible keywords in this forum are: orphan, WeakHashMap, Unreferenced.

Regards, Andrew
 
Jan Groth
Ranch Hand
Posts: 456
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@olena

good idea, but what immediately came accross my mind - this solution will only work with a additional business level? something like a DataAdapter or so, which takes control over who is locking what. A test class working with Data.java will be able to deadlock you scenario, right?

@frans

we met before, in a thread started by olena, right ? :-)
-> here <-
like you said, you need to find out if a client is a valid lock owner. this means another level of information into the locking data structure. okay.

@frans, olena

another aspect of this issues: what if a client simply dies or freeezes after locking a record? say the vm terminates while still holding locks. do you think this is our problem? ;-)
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

@frans

we met before, in a thread started by olena, right ? :-)


Could well be! I am in too many threads these days

@frans, olena

another aspect of this issues: what if a client simply dies or freeezes after locking a record? say the vm terminates while still holding locks. do you think this is our problem? ;-)


As Andrew pointed out above, this is probably beyond the scope of the assignment. However, my pride as a software engineer urged me to address the situation nonetheless. I used the method described above by Andrew as not being according to the spirit of the assignment (I would cancel a lock after a certain amount of time).

Frans.
 
Olena Golub
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jan,
sorry I forget to write about my design. I do use DataAdaptor. Every Client has its own instance of the DataAdaptor.
I permited my Client to book only one record at time. It's mean, if another
record is already locked by this client, the client could not lock the another or the same record.

I defined one boolean variable something like:

hasClientLock

And after the lock method is called I check this variable, if it's true - trows the exeption, and if false make the locking. After the record will be locked I put this variable to true. In the unlock, after I delete the locking record with the cookie from the array where I store it, this variable receives false.


another aspect of this issues: what if a client simply dies or freeezes after locking a record? say the vm terminates while still holding locks. do you think this is our problem? ;-)


If the client dies or freezes I use Unreferenced (I use RMI).
I am not sure if my idea is correct, but it's only my proposition

How do you think is this idea Okey?
Regards, Olena
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic