I am just bouncing this off you guys to see what you think. I have been thinking about how the Lock and Unlock code needs to know who the client is, and in some posts, people have suggested a Connection Object. I thought, instead, would it be easier and maybe better, if the server object assigned a unique client ID to each new client. Meaning when the client starts up and calls for the remote interface, that the server passes back a unique number, basically saying, "Hey, as long as you are running, please use this unique number to identify yourself" What do you think? Mark
Two consequences of this design. 1. You would have to either modify the signature of the lock/unlock functions, or create an adapter class specifically to transform between "id-less" lock/unlock and "id-taking" lock/unlock. The former is against instructions (since you do IMHO not have sufficient reason for it) while the latter is additional clutter. 2. It becomes much more difficult to clean up after dead clients. If you give each client its own Connection object, you can use RMI distributed garbage collection (cf Unreferenced) to clean up a crashed client's locks, with almost no effort on your part. - Peter
Well, in my instructions, it did not say I couldn't change the signature of the lock and unlock methods. I do agree that it does not handle the crashing client, but I wonder if they would knock off points because of it. Yes in the long run on a real application that would be a problem that had to be addressed. But I am not too sure if they wouldn't overlook it, because they are more interested in a running application. I just really don't understand the Connection Object. I can't picture it, and I think there seems to be a lot of work to do to get it to work. Thanks Mark
Why don't you get the client host by calling String host = java.rmi.server.UnicastRemoteObject.getClientHost(); in the lock method? Then you could add the passed record number (as the key) and the client host (as the value) to a hashtable and lock this record when another client tries to access this record. The same way when the client unlocks this record: get the client host and remove it with the passed record number (as the key) from the hashtable... Tom
Peter den Haan
Joined: Apr 20, 2000
Originally posted by Thomas Suer: Why don't you get the client host by calling String host = java.rmi.server.UnicastRemoteObject.getClientHost(); in the lock method?
Personally, I considered and rejected it. That would work for single-user Windows boxes, but not for multi-user Unix boxes. Not to mention that machines on company networks often have internal, non-routing IPs that get translated at the firewall. I don't want to know what that does to getClientHost(). But the clincher was really that the instructions said that the database was to be built for re-use in other project. One client per host is IMHO an unreasonable restriction for a generic database library, even if it would be OK in the context of the Fly By Night project. - Peter