This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes How do I share Database between threads yet still keep a unique clientID? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "How do I share Database between threads yet still keep a unique clientID?" Watch "How do I share Database between threads yet still keep a unique clientID?" New topic
Author

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

Sudhir Rajbhandary
Greenhorn

Joined: Aug 03, 2001
Posts: 1
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.
Sajid Raza
Ranch Hand

Joined: Jul 13, 2001
Posts: 41
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.
Rick Fortier
Ranch Hand

Joined: Jun 04, 2001
Posts: 147
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?
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: How do I share Database between threads yet still keep a unique clientID?