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

Potential deadlock scenario

 
Pete Palmer
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi

The following are the provided methods on my DBAccess interface that I need to support.

I am implementing a thick client approach so for example, an update operation, client A will invoke
1) lockRecord ()
2) updateRecord ()
3) unlock ()

If Client B also performs an update on the same record, it will have to wait until client A has released the lock on the record. As expected.

The GUI will only permit a client to perform a single action at any one time, so therefore, in the above scenario, Client A would not be able to perform any other operation until the current request has completed. Effectively this approach will ensure that a client will not be able to lock the same record twice from the GUI.

However, if Sun's tester class is going to access the Data class directly, then it is possible for it to have a scenario where by client A locks a record and then client A attempts to lock the same record without releasing the original. My current design will cause a deadlock.

Any suggestions to overcome this issue please.

Thank you

Pete
 
mohamed sulibi
Ranch Hand
Posts: 169
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Pete;

thank you for your post and I am with you.

regards.
Mohamed Darim
SCJP, SCJD in progress (From 1/8/2007 till now).
 
Alecsandru Cocarla
Ranch Hand
Posts: 158
 
Pete Palmer
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Alecsandru,
Umm.... that's interesting!

So, if I understand this correctly, what you are saying is that there is no specific requirement to handle this scenario and therefore, you did not support it. Is this correct and if so, did you simply put this down in the design document. I think Samuel's response seems to suggest this but it is not explicit.

My requirement for the lock() is below:-

Incidently, I haven't got to the GUI design yet but when I said
The GUI will only permit a client to perform a single action at any one time, so therefore, in the above scenario, Client A would not be able to perform any other operation until the current request has completed. Effectively this approach will ensure that a client will not be able to lock the same record twice from the GUI.

This is how I perceived my GUI behaviour. It sound like you also had a similar approach. It re assuring to know I am on the correct track.

Many thanks

Pete
 
Alecsandru Cocarla
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's not only in the decisions document, but also in the javadoc of the lock() method, because it's something the users of the Data class should be careful about. I also added a javadoc section about how multiple locks should be acquired in the order of the recNos, in order to avoid other types of deadlocks.
 
Pete Palmer
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Alecsandru,

As you said, the issue is with respect to the users of the Data class - the GUI and Sun's test harness. If it was required to prevent such a deadlock scenario, I presume the Sun's interface class (DBAcess) would need to be extended to provide some means of determining the identify of the client that is locking/unlocking a record ?
I also added a javadoc section about how multiple locks should be acquired in the order of the recNos, in order to avoid other types of deadlocks.

Would you be able to elaborate above alittle please. Unfortunately, I don't fully appreciate when you say the order of recNos…

The only time I lock a record is for a delete ( lock(recNo)-> delete(recNo)->unlock(recNo) ) and update ( lock(recNo)-> update(recNo)->unlock(recNo) ) operations.

Thank you

Pete
 
Alecsandru Cocarla
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You should not think only at your GUI layer and at the SUN assessors as "users" of your Data class. If that would be the case, then you wouldn't need javadoc/documentation at all, since you and also the assessor probably know what is all about. Your mind should be set as if somebody else might use your classes, maybe later, and maybe even outside the current project.

Regarding the "order of RecNos" affirmation: this is also mentioned in "the book" - when a client tries to acquire multiple locks (without first unlocking), this can solve the problem of two clients which try to lock one another's already locked records (X locked rec A and tries to lock B, while Y locked rec B and tries to lock A).
 
Pete Palmer
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alecsandru,
Your mind should be set as if somebody else might use your classes, maybe later, and maybe even outside the current project.

Thank you for putting me straight. Been on this assignment for 2 months plus on & off and my focus is obviously straying !!

(X locked rec A and tries to lock B, while Y locked rec B and tries to lock A).
Accept this point and just to clarify.... however we can't detect this scenario either with the provided interface, and as with the previous case, need to document it .... with words to the effect that the user of the data class has to ensure that it ONLY locks one record at any one time, failing to adhere to this may result in a deadlock situation. Is this about right ?

Thank you.
Pete

 
Alecsandru Cocarla
Ranch Hand
Posts: 158
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
At least in my case, I could not detect the first scenario, because my assignment had cookies. I don't know which version you have. Without cookies, it's possible to identify a client by the Data class instance it's using, and let it reacquire a lock it's already holding. So, at least the first type of deadlock (one client tries to lock same record twice) can be prevented.

For the second one (with two or more clients involved), the solution is to document restrictions to the class users:
- either lock only one record at a time or
- lock the records in the order of their recNos.

The second approach is valid because (consider the case with X, Y, A and B mentioned before). Consider A < B. In this case, if client Y already locked B it should not try to lock A, because A it's not > B. So, deadlock avoided. This stuff is transitive, so it can be applied to any number of clients.

However, you can't check and enforce this in the code. Or maybe you could, but it's too complex for this project (at least, I can't think of an easy way of doing it). That's why I say - just javadoc this and leave it to the user. You're going to lock one record at a time anyway, so there's no need to bother implementing complex logic for this.
 
Pete Palmer
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alecsandru,
Once again, to the rescue. Thank you for the explanation & clarification. Now to document this before I forget !

Good evening.
Pete
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic