42
Possibly a slight difference of opinion here ...Originally posted by Jeroen T Wenting:
It's effectively impossible to determine the actual client making a request.
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Originally posted by Jeroen T Wenting:
It's effectively impossible to determine the actual client making a request.
You may argue that you don't need it for lock(), but you most definitely need it for update() and delete(). You must be able to determine whether the caller owns the lock on the record it wants before you allow either of these actions.
I had first implemented it in such a way that the client could not be identified, but soon found out that this didn't meet the requirements which say clearly: "Locks a record so that it can only be updated or deleted by this client." When I noticed this, I did a search on this forum for the expression "identify client" and ended up reading about this for hours. I recommend you do the same.
This thread contains a collection of threads (it's in Andrew's first post) that may be particularly helpful.
SCJP , SCJD. (IBM 142 in progress).
42
If you are trying to identify a particular client where each individual client can have multiple connections open to the server, then it can become an interesting exercise to set up a safe way to identify the client. It can be done, but you are probably going beyond the requirements.
If you are trying to identify a particular client where each individual client can only have a single connection open to the server, then it is relatively easy to do.
42
No, I have no requirements for a single machine in my definition. I was trying to limit the number of connections per client just to keep things simple, but that was my only requirement.Originally posted by Jeroen T Wenting:
I define "client" as a single instance of the client application software running somewhere.
You apparently define it as a single machine on which any number of instances of the client application software may run.
But that wont work if your definition of a client is just that it is running somewhere, because that definition could allow two clients from the same machine (or IP address).Originally posted by Jeroen T Wenting:
Identifying the IP address of the machine the client runs on is indeed not hard (I do that now when in networked mode, refactored the entire lock mechanism for that last night while making it more generic at the same time), ...
Working with a UID will provide a reasonably reliable system, and I believe it is a very simple system to implement. But it is not necessary if you are willing to look at a Connection Factory on the server side (and, yes, I am aware that you have earlier stated that you believe that this is more complicated than is needed for the assignment. But I think it is an easy solution, and at 13 extra lines of code for the server and 1 extra line for the client, I dont think it is too much extra work).Originally posted by Jeroen T Wenting:
identifying the client instance is indeed a lot harder (especially when using RMI, though it does look to be possible (have to give it some thought) by some sort of UID system).
The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog