• 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

lost in different implementations of locking

 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 451
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have not worked on the real exam yet.

But why setClientId(currentThread().getId()) will cause a deadlock?
 
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
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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic