This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLyBird 1.3.1 How to identify clients? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLyBird 1.3.1 How to identify clients?" Watch "URLyBird 1.3.1 How to identify clients?" New topic
Author

URLyBird 1.3.1 How to identify clients?

Alexander V Fahrmann
Greenhorn

Joined: Jan 16, 2008
Posts: 22
Hi, ranchers.

Unfortunately, the lock method of my DBMain inteface does not return cookie and so, the interface has no means to identify clients, but the assignment requires that the lock method must lock "a record so that it can only be updated or deleted by THIS client".

I am going to use RMI, and having intended to use thread id as the client identification I came accross this:
A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads. Since remote method invocation on the same remote object may execute concurrently, a remote object implementation needs to make sure its implementation is thread-safe.


Are here any native speakers? What this quotation means exactly?
Does it mean that it is possible that the sequence of INSTRUCTIONS of one method invoked by one client could be mixed (haphazardly!) with the sequence of INSTRUCTIONS of (possibly the same) method invoked by another client, and both sequences to be stuffed in the same thread of execution?

I am going to use lock-process-unlock sequence within a single RMI call, so if the above mentioned scenario is possible - I must to refactor my solution:

You see in that case:
1. Client A invokes book method (that is: lock-process-unlock);
2. Client B invokes book method;
3. Server mixes instruction sequences from both invocations into a single thread -> so, both clients will have the same thread id;
4. ... trouble with locking.

Or, maybe, the quotation states that the instructions comprising one method invocation will be used as one single bunch and will not be interspersed by instructions from another method invocation (even if both method invocatons take place within the same thread - but sequentially: instructions of one thread will be processed only after completion of processing of all instructions of the other thread) - in that case it is feasible to use
thread id as the client identification for sure.


SCJD, SCBCD, SCWCD
Simon Hogg
Greenhorn

Joined: Jan 29, 2008
Posts: 7
The quote is trying to say that, in the server, the thread that handles one request from a client is not guaranteed to be the one that handles other requests from that client. A whole remote method will be handled by one server thread (unless you create more inside the method).

You couldn't lock(), update() and unlock() from the client as separate remote methods, you have to handle those on the server and export only one method that internally calls the others.

There is no haphazard mixing of instructions from different clients in the same thread, so your method of locking on thread ID should be fine.
 
GeeCON Prague 2014
 
subject: URLyBird 1.3.1 How to identify clients?