aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Client Identification Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of JavaScript Promises Essentials this week in the JavaScript forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Client Identification" Watch "Client Identification" New topic
Author

Client Identification

Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17259
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
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
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17259
    
    6

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
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17259
    
    6

OK the lightbulb went off in my head, and now I understand the Connection Object approach. It now makes perfect sense.
Mark
Siddharth Mehrotra
Ranch Hand

Joined: Aug 21, 2001
Posts: 185

hi there,
i was going through your decesion on lock and unlock,
can anyone explain me the connection object.
whats that.
thanking you all in advance

------------------
Sid


SCJP, SCJD.
Thomas Suer
Ranch Hand

Joined: Sep 03, 2001
Posts: 50
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
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
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
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Client Identification