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: deadlock by definition?

 
Stephen Galbraith
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone,
I've been bugged by the following for a while now, but the instrctions seem to imply allowing a deadlock situation at the core database level. It's the old "consuming zero cpu cycles" thing on the wait when a record is locked by another client.
Let me paint a scenario.
Client A locks record 1
Client B locks record 2
Client A now attempts to lock record 2 - finds it is locked by Client B and waits.
Now Client B comes along and attempts to lock 1 - finds it is locked by Client A and waits.
now we have deadlock!
Okay - so it reality it would "never" happen as my buisness logic doesn't allow a Client to leave a record in locked situation (as the only locking thing they can do is "book" (which at the database level does lock->book->unlock (and I do make sure that if the Clinet goes down then the lock is released )). But I don't want to fail!
So am I fundamentally flawed in my design? Should I only allow one client to obtain one lock ever (but this sounds restrictive for future modifications!)?
Is documenting this "flaw" in the choices okay?
Help
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Stephen,
Originally posted by Stephen Galbraith:
Okay - so in reality it would "never" happen as my buisness logic doesn't allow a Client to leave a record in locked situation (as the only locking thing they can do is "book" (which at the database level does lock->book->unlock (and I do make sure that if the Clinet goes down then the lock is released )).

A question about your application. If a client attempts to book a record that is already locked, isn't this client placed into a wait state until the other client unlocks the record? In other words, is it even possible for this client to attempt to book a second record while waiting for the lock on the first record? If the answer to these questions is "No," then I don't see the potential for deadlock. If the answer is "Yes," I would be tempted to think about changing that situation as it does seem to permit deadlock.
So, if you prevent deadlock the only thing I would say in the design choices document is that you prevent deadlock and how you do that. For example, by saying something like the quote above. On the other hand, I wouldn't document that there is a potential for deadlock in the design choices document, because I would hope that wouldn't be the case.
Hope this helps,
George
[ January 21, 2004: Message edited by: George Marinkovich ]
 
Stephen Galbraith
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've gone for the making the Client wait until the booking happens i.e they cannot book another record until the other request has been handled.
But my buisness logic sits on the Client . Therefore if someone implemented a new version of the Client along with my version of the server,
we could have deadlock.
What do you think? Would SUN fail me because although in my APP deadlock is impossible, it's not impossible if someone extended it in the future?
 
Ken Krebs
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sounds like a strong argument for the 3-tier approach where the client is not given access to the locking API.
 
Xie Ruchang
Ranch Hand
Posts: 160
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One of the conditions which deadlock could happen is hold and wait. BUT if the application is designed in such a way in the sequence of acquiring resources, deadlock could never happen even for the hold and wait situation.
One way if to determine beforehand the order of acquiring resources. For example. the processes must be have A before waiting for B and before waiting for C.
Then situation like
Process 1 : Acquired A ---> Waiting B
Process 2 : Acquired B ---> Waiting A (not allowed)
WILL NOT happen.
If this is not possible, deadlock resolution is performed by time-outs. This is where the lock cookies based on System time is better than a random figure. The system auto scans the cookie than are timeouts and released the locks. For long transaction, the processes have the responsibility to refresh the locks so that they do not get timeout.
 
Stephen Galbraith
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the input so far.
What I'm hearing is that as long as I document that it is only possible to call "book" from the client and I handle possible errors (so as to not leave the record locked) then I should be alright. Correct?
I could enforce "one client one lock" rule on the server (which would prevent any possibility for deadlock), but I'm not keen as I think I could be creating rules which aren't in the spec.
Have other "thick client" people enforced this? I want to be safe, but I don't want to revisit my other decisions if I don't have to!
Steve.
 
George Marinkovich
Ranch Hand
Posts: 619
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Stephen,
Originally posted by Stephen Galbraith:
What I'm hearing is that as long as I document that it is only possible to call "book" from the client and I handle possible errors (so as to not leave the record locked) then I should be alright. Correct?

Yes, I think so.
By the "one client one lock" rule do you mean that each client can only ever have at most one lock at a time, or do you mean that there can only every be one lock held (in the entire database) at one time and that this lock will be held by only one client? If you mean the former, then I don't see that you're introducing any unwarranted restriction that isn't present in the specification, and moreover I don't think you have introduced a deadlock possibility by doing so. If you mean the latter, then I think that's a pretty drastic step and would advise against it as it is a serious limitation on concurrency.
Hope this helps,
George
 
Stephen Galbraith
Ranch Hand
Posts: 90
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry for not getting back sooner, busy at work (would you belive trying to persuade then that unit testing is worthwhile ). Thanks for you comments. They give me a bit more confidence.
Yeah I did mean the former, and I realise that way I'd remove all possibility of deadlock, so that'd be "safer" than what I've currently got. But I've still got this nagging feeling that I'm restricting the use of the server by making this rather drastic rule, but then if I'm that worried about deadlock... I guess it's a balance.
So I'll document and go with what I've got (i.e. allow one client to hold multiple locks at the DB layer, but not allow this on the client side). Unless anyone has strong opinions on the subject?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic