• 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
  • Ron McLeod
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Frits Walraven
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger

How do I share Database between threads yet still keep a unique clientID?

Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand how to generate unique clientIDs and I understand that in order for synchronization to work on Data my threads must share the same instance of the Data Object. I even understand how to use the hashmap to lock and unlock records with clientID. What I don't understand is how using the given signature for lock/unlock (that is with passing in only a recNumber) I can lock and unlock the records with the clientID.
If all threads are sharing the same instance of Data then they share any member variables as well. So unless I change the lock method to accept both a recNumber parameter and clientID, I don't see how I can do this!
Any help would be much appreciated.
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Most people who went the client id route changed the method signatures. All you need to do is justify your decision to change the signature in your documentation.
Ranch Hand
Posts: 147
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
After I completed this assignment, I had a discussion with someone else about another way to do this. I did not code it that way, and so this thought is not completely thought out in my mind.
If the client calls the RMI interface on the server which creates a connection object, and returns this object to the client, then this connection object can be used to uniquely identify the client on subsequent calls.
This would mean that the collection object would create a unique id, maybe by using the UID class, and use this uid to lock the record. So when the client called lock(int) as a method of the connection object, then the object would know who the caller was.
Somehow the connection object would have to have access to a singleton class which held the current locks collection.
This would allow you to uniquely identify the user's session and you would not have to modify the lock/unlock signatures.
Any thoughts?
Happily living in the valley of the dried frogs with a few tiny ads.
Devious Experiments for a Truly Passive Greenhouse!
    Bookmark Topic Watch Topic
  • New Topic