|
![]() |
1. Ignore the issue - just make sure that the client you write can only lock one record. It's a very acceptable solution IMO, but I would document that a deadlock - at the db level - may occure, while it cannot happen in this application (because users cannot book more than one record at a time).
2. Force the database to reject any lock() requests if the given client attempts to lock a record while it currently owns a lock : at the db level it is a restriction in comparison with what the instructions ask.
3. Stop the possibily of deadlocks by forcing locks to be requested by a client in numerical order. It is a restriction. Nowhere instructions talk us about any required order in lock claiming.
4. Stop the possibility of deadlocks by writing a deadlock detection routine : there is no restriction to the instructions, because the given lock interface may freely be used as exposed (including the grant of multiple locks to the same client), while in the same time deadlocks cannot happen.
1. (Ignore the issue) Seems like many developers have used this approache and passed with 100% for locking(correct my if I'm wrong). And this one is he most logical, since assignment states that systems will not be reused in future, so why should we bother with functionality, which will not be used at all(we lock one record at a time)?
4. (writing a deadlock detection routine) This is that you are suggesting. But it seems quite complicated - we need to track not only lock owners, but also clients waiting for locks and handle them. Too complicated? Also how about this situation: A locked 1 and waits for 2, B locked 2 and waits for 3, C locked 3 and tries to lock 1. I'm not sure if it is possible to implement easy way to detect this deadlock, also on deadlock detection C should be forced to unlock 3 - not so nice from client C point of view. Maybe I'm missing smth here?
BTW, maybe you can give me more hints how to test deadlock detection logic besides that A,B,C locking situation. I can not figure out more complicated one(more clients do not make that situation more complicated since code is recursive
). IMO any attempts to test that logic with many running threads may miss some situations. Any ideas? Thanks.
BTW - that pseudo code came into my mind just after reading in this thread that it took for you only 15 lines of recursive code to check for deadlock. So I've kind of plagiarized from you
![]()
hope you enjoy this quite interesting post as I am
All of the world's problems can be solved in a garden - Geoff Lawton. Tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
https://coderanch.com/t/704633/RavenDB-Open-Source-NoSQL-Database
|