File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes choices and deadlock Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "choices and deadlock" Watch "choices and deadlock" New topic
Author

choices and deadlock

Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
Hi,

I'm just overworking my choices and came to my locking section. I allow a deadlock to happen if on server side a thread tries to lock a record, which it already possesses.
Can you tell me, if my reasoning for the choices is ok:
I reasoned, that the deadlock can only happen on client side and that it can't happen in my application. Also, that it would complicate the code to avoid the deadlock and therefore the readability for the junior programmer.

Is that enough for explaining a deadlock?

Thanks for your help.
cheers
Bob


SCJP 6 - SCJD - SCWCD 5 - SCBCD 5
JavaEnterpriseEditionFaq - TomcatFaq
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 2231
    
    7

Hi Bob

If you have deadlock on client or server side, you will fail. If client A is updating say record 1 (meaning your server is locking record 1), and client B comes along and also try to update record 1, then client B wait until client A finishes his update and then when B actually try to update would prompt an error saying record 1 is already booked preventing client B to update.

Deadlock issue is really on the server side if you are using a service layer. If you expose lock() and unlock() methods to the client then it becomes client side.


K. Tsang JavaRanch SCJP5 SCJD/OCM-JD OCPJP7 OCPWCD5
Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
Hi K,
a light in the darkness
K. Tsang wrote:
If you have deadlock on client or server side, you will fail. If client A is updating say record 1 (meaning your server is locking record 1), and client B comes along and also try to update record 1, then client B wait until client A finishes his update and then when B actually try to update would prompt an error saying record 1 is already booked preventing client B to update.

Yeah, that's the booking algorithm and it's working. No problem here. I prevent any deadlock triggered from client side. The same client can't lock the same record here. But if automatic testing does something on server side like lock(1), lock(1) (in one thread) I experience a deadlock.

K. Tsang wrote:
Deadlock issue is really on the server side if you are using a service layer. If you expose lock() and unlock() methods to the client then it becomes client side.

Yes, I use a service layer. I found a post by you (Post), where you said, that you allow a deadlock to happen (am I right?). How did you justified it in the choices?
K. Tsang wrote:
... In my case if the same client does call lock(1) twice, that thread will deadlock waiting for itself. Of course we shouldn't expect that.


Thanks for answering.
cheers
Bob

Edit: Link stuff.

Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5126
    
  12

Hi Bob,

If an automatic test-program on the server tries to lock the same record twice, an IllegalStateException will be thrown. So no deadlock and an exception being thrown because it's abusive use of my API.
Same remark if a client (or test-program) tries to lock another record already owning the lock on another record.

Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
Hi Roel,
Roel De Nijs wrote:
If an automatic test-program on the server tries to lock the same record twice, an IllegalStateException will be thrown. So no deadlock and an exception being thrown because it's abusive use of my API.
Same remark if a client (or test-program) tries to lock another record already owning the lock on another record.

Yes, but the problem here is to identify the client if you have the lock method returning a lock cookie. As far as I know this can't be done w/o complicating the code.
My lock requirements state that a "different client" should give up CPU, if record is already locked. Nobody said that the same client shouldn't do the same. So it wouldn't harm anything. And furthermore, I don't expose the lock/unlock method to the client anyway. So this (double-lock) deadlock is just happening theoretically, except for some devilish automatic testing program. My solution would be to explain this in the choices and add a line to lock's javadoc (first sentence already in the javadoc):
If the specified record is already locked by a different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked. When a client tries to lock the record while already holding its lock may lead to a deadlock. It is the responsibility of the client to avoid it.

I know some coders did pass with a similar approach. But was it luck? I don't know.

Any opinions?

cheers
Bob
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5126
    
  12

Hi Bob,

If other coders passed with a similar approach I don't think it was luck. But I don't know of a rock solid solution to prevend deadlock with a lockCookie, besides mentioning in javadoc and choices.txt
And because you mention it in your choices.txt you certainly have thought about it, so that's a good point. If you don't mention it at all, it seems to the accessor that you don't know deadlock could happen (and maybe losing some points in the locking section)

Kind regards,
Roel
Bob Wheeler
Ranch Hand

Joined: Apr 24, 2009
Posts: 317
Roel De Nijs wrote:
If other coders passed with a similar approach I don't think it was luck. But I don't know of a rock solid solution to prevend deadlock with a lockCookie, besides mentioning in javadoc and choices.txt
And because you mention it in your choices.txt you certainly have thought about it, so that's a good point. If you don't mention it at all, it seems to the accessor that you don't know deadlock could happen (and maybe losing some points in the locking section)


Thanks a lot for your answer.
Have a nice weekend.
cheers
Bob
Dennis Leong
Greenhorn

Joined: Jul 08, 2009
Posts: 9
Interesting!, i never thought about these possibilities for deadlock, but tested them out on my app and it's certainly a problem (for malicious coded clients only).

Roel - out of interest, how do you know when to throw an IllegalStateException ? is it done in your service layer method ?, as i cannot see how you could uniquely identify the client with the Data class lock() method.

Thinking about it, you could accept a unique client JVM identifier to your book method, then as part of your book method that uses lock(), you could concatenate it to the generated cookie, storing these values on your server. You could then enforce clients to only hold one lock at a time, or just return the same record number cookie. That is also introducing another layer of abstraction above your Data lock() method, as you cannot add this unique identifier as a lock() parameter, it must be implemented as is (just the record number). And since (presumably) the automated testing program would only test your Data class directly, without considering your service layer methods, then it's probably not something your going to be able to cater for, unless anyone's got any other ideas??

i tend to agree that it's over complicating things and beyond scope, and i haven't read of anyone else going to these lengths to prevent such deadlocks.




cheers,
D
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5126
    
  12

Hi Dennis,

My lock-method doesn't have a lockCookie, so I had to come up with some way to uniquely define my clients. I didn't use the RMI Factory Pattern (as described in andrew's book) but (inspired by the great Roberto Perillo) I generated for each client a unique id and via a set-method on my Data class I set the client-id, then call lock and then reset the client id. All this must happen as an atomic operation.


And of course same code for update, delete and unlock.

In my Data class I keep a map with recNo-clientId pairs, so I can easily check if a clientId already occurs in this map, which would mean client is already owning a lock.

This approach is for network part, in local mode I don't use a generated id, but simply the id of the current thread.

Hope it makes sense (and it's understandable)!
Kind regards,
Roel
Dennis Leong
Greenhorn

Joined: Jul 08, 2009
Posts: 9
great, thanks Roel.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: choices and deadlock
 
Similar Threads
deadlock
urlyBird 1.2.3
NX: deadlock by definition?
Threads again...
Passed 360/400