aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes lost in different implementations of locking Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "lost in different implementations of locking" Watch "lost in different implementations of locking" New topic
Author

lost in different implementations of locking

Margarita Babkova
Ranch Hand

Joined: May 09, 2012
Posts: 32
Greeting all,

I am lost and really need advice.
I finished work on my Data class with lock methods using reference this as to keep track of unique clients. I tested it with Roberto Perillo Test class (all worked like charm – Thank you very much, Roberto).
But the moment I start working on RMI – I decided that I do not really like fact that I will have to provide each client with own instance of data, and my client would be a ‘fat’ client. Yes, it took me awhile to finally understand what I was doing…

So, I decided to try different approach and keep individual client id in my LockManager class like

And then just have to call it from my Data class lock. So, my modified Data class got private field clientID and public setClientID method

But here is comes a trouble: I am not sure I am doing things right: when I ran the same Test class ( with sequence lock, update, unlock) - ALL WORKS FINE, but should I be using my setClientID method call in this Test class? Because if I do set it to the current thread id – I am getting dead lock...

I am planning to use setClientID method on a server side book method: book(){ setClientId, lock, update, unlock}, to make sure that my lock method gets unique clientID (long clientID=system.nanoTime().
I have to start working on RMI part, and settle on either locking approach.

thank you in advance,
M
Helen Ma
Ranch Hand

Joined: Nov 01, 2011
Posts: 451
I have not worked on the real exam yet.

But why setClientId(currentThread().getId()) will cause a deadlock?
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5212
    
  12

Your design like you showed here is not thread-safe at all. And that's really a big issue

Based on your code snippets, your lock-method doesn't have a cookie-parameter. So you have to use a mechanism to identify your clients uniquely. Using some kind of client-id (System.nanoTime() is a good approach (one that I used too ) But what's very important in this approach (and that's lacking in your sample code): setting the client-id and invoking a business method (lock, update, delete, unlock) must be thread-safe (executed as an atomic operation). If it's not, you'll fail!

Try searching this forum for setClientId and/or clientId because there are a lot of topics about this approach (with some nice discussions).


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

Joined: May 09, 2012
Posts: 32
Thank you, Roel.

I read your suggestions and Roberto from the past about this setClientID business. As much as I like to go that road – I have to invest more time in to solving locking.
At my rate of progress, I better stick to initial locking design with references to the data instances. Get RMI use factory method to serve these instances and deal with thick client.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: lost in different implementations of locking