Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Unique Client ID

 
Mike Wiegand
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,
I am using RMI for my communication link and am having a very difficult time trying to get a unique id for use by my lock/unlock. On the server, if I use Thread.getCurrentThread().getName(), I get a unique id which may be different the next time I connect. So, if I do a lock() and the server uses Thread.getCurrentThread().getName() to generate an ID, the server may not be able to generate the same id from the same client on the unlock(). So, where do I get a unique id for lock/unlock from?? I do not think that I can pass an id in the lock call like lock(recordNum,clientID). This would violate the design spec, wouldn't it??
Any help would be greatly appreciated!!!
Thanks
Mike
 
Sajid Raza
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The RMI spec. does not guarantee a unique thread for remote method invocations. As you've experienced you can't use the thread as an ID.
Most of us have created our own unique ID and passed that into lock and unlock. You could make your ID as simple as a private int field that you increment for each new client and give the new client the current value of the int. I would suggest looking at two classes to get an idea of building a rock-solid ID: java.rmi.server.UID and java.net.InetAddress.
[This message has been edited by Sajid Raza (edited July 27, 2001).]
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How about making each client hold a reference to an object which is 100% dedicated to that client??? I mean, instead of having a single Data object bound to the RMI registry, you would use a Data Factory, and request it new instances of "dedicated" Data objects (which all wrap a unique instance of a Data Object).
In this way, you don�t have to modify method signatures (which I personally dislike), neither pass extra parameters in your methods...
Hope this helps!!!
Benjam�n
 
Sajid Raza
Ranch Hand
Posts: 41
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Benjamin. Creating multiple instances server side presents a very clean interface to the client. You are still going to have to track client id's internally somewhere in one central place.
 
pooja vij
Greenhorn
Posts: 20
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello Mike,
i have got certain doubts on ur question regarding client tracking
1) whenever u refresh the connection to server(connect again)
the client always takes a new thread. and Thread.currentThread.getName() will always be different than u were connected earlier but if u don't dissconnect the same thread id shall be maintained and this functionality can be used in the client Tracking.
U can also use other means like creating a new Object or some other means to track a client(in ur lock method) but consider tghe scenario where a clientA has acquired a llock on rowid 10. now suppose a clientB which has not acquired a lock on the Same rowid(in this case 10) but calls the unlock method delibreately.If i had used any Object Other then Thread then ur container's(like Hashtable,hashmap,etc.)then containers get() will return some value and subsequently u unlocked the record.This will corrupt the Database file as the clientA may have not finished its operation.So i think best way out is to keep the track of thread.

pooja

 
R Bischof
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Benjamin,
excellent point (and so easy). That way you can also identify dead clients and remove their existing locks.
I have build another -much more complex- solution for this but I guess I have to re-think it...
thx
rainer
 
Anonymous
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Another advantage of using a unique remote object for each client is that you can perform any clean-up operations, suchs as releasing locks erroneously held by the client, when the remote objects becomes unreferenced. In order to do this, the object must implement the java.rmi.Unreferenced interface. Read the Java API for further details....
Hope this help!!!
Benjam�n
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic