• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Deadlock dilema

 
Jon Entwistle
Ranch Hand
Posts: 118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I have being reviewing my code before I upload and there is one thing (at the moment!) which I am not convinced about.

I am (reasonably) confident that my synchronization will prevent deadlocks in all but one scenario:

--------------------
Client A locks record x
Client B locks record y
Client B tries to lock x - forced to wait
Client A tries to lock y -> deadlock
--------------------

Of course, this scenario can only happen if clients are allowed to lock more than one record at once. Is it a reasonable assumption to make that locks will only lock one record at a time? In the scope of the assignment, should we cater for this?

I have not implemented a lock manager - Data deals with locking alone in standalone mode. In remote mode, I have one connection object per client acting as an Unreferenced proxy for Data by implementing DBRemoteInterface (I keep track of all cookies and record numbers in a Map in Connection and have unreferenced() call unlock for each one in Data in case of a crash).

I could abstract the 'locking memory' in each Connection object into a separate singelton class which checked for this deadlock - but am I going too far?

Thnaks for any thoughts.

Jon
 
Pedro Penna
Ranch Hand
Posts: 46
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I don't think you need to implement this kind of deadlock-safe mechanism, because (at least for my assignment - URLyBird) no operation requires two records to be locked at the same time.
 
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 Jon,

There are many ways you could deal with this. To name but a few:
  • Document in your design choices document that this is a potential problem but it cannot happen with your clients, and you didn't implement any handler for it as that is out of scope for this assignment.
  • Disallow locking of more than one record by any one client at any one time.
  • Only allow locking of records in numerical order (If client A has locked record 5 then they cannot attempt to lock record 3 as it is out of numerical order).
  • Implement a recursive deadlock checker (easier than it sounds).


  • I know the first two options have been successfully used in the past. The third option seemed to have a lot of favour a while back, but I don't recall anyone specifically saying that they were implementing it and afterwards stating that they passed. I am eagerly awaiting hearing that the fourth option has been submitted and passed (I know someone who has implemented it, but not yet submitted it).

    Regards, Andrew
     
    Jon Entwistle
    Ranch Hand
    Posts: 118
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks Andrew,

    Looking at the scope/requirements of the assignment, I think your second option is the best tradeoff. Locking more than one record is not a requirement and coding for it would probably be overkill, but on the other hand if the server cannot cope with such a scenario it should not be allowed to arise.

    I have made my remote Connection objects throw a RuntimeException when trying to lock more than one client and documented it.

    Regards,

    Jon
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic