• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

choices and deadlock

 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Bob Wheeler
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Bob Wheeler
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.



 
Roel De Nijs
Sheriff
Posts: 11604
178
Hibernate jQuery Eclipse IDE Spring MySQL Database AngularJS Tomcat Server Chrome Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
great, thanks Roel.
 
reply
    Bookmark Topic Watch Topic
  • New Topic