• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

lost in different implementations of locking

 
Margarita Babkova
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have not worked on the real exam yet.

But why setClientId(currentThread().getId()) will cause a deadlock?
 
Roel De Nijs
Sheriff
Posts: 10457
137
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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).
 
Margarita Babkova
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic