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.
acutally I can't understand above statement very well, does that mean rmi server could assign one thread to different client at same time?
is this the reason which make a client could unlock a record that it has not locked?
To connect with your server, you should create a client program. This implementation should include a class that implements the same public methods as the suncertify.db.Data class, although it will need different constructors to allow it to support the network configuration."
Originally posted by Reza Rahman:
P.S.: This seems to be a common misconception on this board, so I am glad you finally brought it up...I think there are two additional factors other than the poorly worded spec leading to misundertanding the spec's intent...a tendency to favor the two-tier/RMI factory patterns and paranoia about being "extra safe" - both harmless and well-intentioned, of course...but it binds the rest of us to an assumption that just isn't true other than unsubstantiated claims/inferences repeated in no other place than this board...
If you do have this, then you need some way of ensuring that only the client that locked the record can unlock it, and just assuming that your server code won't unlock a record it did not lock does not meet this criteria - the Data class still does not meet the requirements.
Locks a record so that it can only be updated or deleted by this client.