I am using the system time (in milliseconds) to identify the client. Is that enough? i.e. Do we have to consider what if two clients are trying to connect to the server within 1 millisecond from two machines? Is it better to use time+IP to identify the client? Or is there other preferred way? Thanks, Cathy
I am using the system time (in milliseconds) to identify the client
Well there is still a small chance that two clients may receive the same Client Id so there should be a better solution that is 100% bullet proof. One solution could be a Factory that uses a singelton cbject to hand out 'access instances' in a synchronized method. Each handed out access instance has an implicit id ar can be assigned an explicit one on handout time. Bern
Originally posted by Mark Spritzler: Or the remote object itself that each client gets is their identity. Meaning you pass this "Connection" object along with the record number to lock the record for the client. Mark
Thanks, Bern and Mark! Mark, I am afraid I did not understand "the remote object itself"? In my understanding, every client gets an instance of the SAME object. Is it right? So, ...
There is a desing in which there is a connection factory that is bound in the registry, when the client starts up in remote mode it looks up the the factory and calls it's one method getConnection(). This method returns a DataAccess class, basically your remote class implemetation of all the Public classes in the Data class. This class extends Remote and UnicastRemoteObject. What this does is it makes the class remain on the server side, now each client then would get their own seperate Connection object that will receive the client's requests. This object can be passed as a reference to your LockManager class, if you have one, or it can have it's own collection or record numbers that that client currently has locked. Hope that makes sense. You can find other threads that explain it in a little more detail here. Mark
By the was, Mark, is the idea for getting ClientID is the Remote object (which extends UnicastRemoteObject and implements RemoteDatainterface). In my design, There is a Factory method pattern which returns the type of the connection (Remote or Local connection). I used Adapter pattern in RMI. I connect Adapter and Factory pattern with a proxy pattern. Here, I still think the idea is to get the Remote object to be the ClientID. and another Question please, How can I test this object to know if it is really a unique ID? is it toString() method enough or anything else? thanks
To be honest I can't give you an exact explaination as to whether it is the ObjectID created, or a different HashCode, but if you remember from the SCJP, the difference between the .equals() method and the == comparator. "==" only returns true if the two references are pointing to the exact same object. The JVM handles all the classes and keeps their IDs so that it can tell which object is which. So since each client gets its own Remote Object created and it resides in the server JVM, then you can be guaranteed a Unique object for each client. I think I got that straight. If I am wrong I am sure someone will correct me. Mark