How do I share Database between threads yet still keep a unique clientID?
Joined: Aug 03, 2001
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.
Joined: Jul 13, 2001
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.
Joined: Jun 04, 2001
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?