Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

RMI and ReadWriteLock pattern

 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I understand that many people have used ReadWriteLock design pattern to implement locking. This pattern relies on all methods by a client to be executed by the same thread...yet RMI spec says that "The RMI runtime makes no guarantees with respect to mapping remote object invocations to threads."
Can anyone explain that?
Thanks
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On the same note, many people claim that their servers do not id clients...that also means relying on the same thread to execute all methods by the same client...by the way, my testing does confirm that a client executes all its methods in the same server thread.
So whats the deal with the spec?
 
Trevor Dunn
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you synchronize your methods into the read/write lock then only one thread at a time can hold the lock for that object. So it does not matter if your rmi call uses different threads or not.
In terms of the client id, I did not keep track of client id at all. It does not mean that everything has to be in the same thread it means that if your locking mechanism is working properly then the client has to always call lock before it calls unlock. This way you ensure that the same client always unlocks their record.

Trevor
 
Angus MacCuish
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In the generic case with lock() and unlock() as separate RMI calls, you surely need some sort of client identification to ensure that only the lock-er can do the unlock (if no there is no guarantee that both methods use the same thread). If you use the concept of a server-side connection or session object for each connected client (created by an RMI factory object) you can use this to distinguish between clients.
Gus
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Trevor,
even if you synchronize your server methods there is still no guarantee that open() and close() by the same client are executed by the same thread.
Angus,
even if you do have a server-based Connection (or Session) object per client, which I do, there is still no guarantee that this object's methods are called by the same thread. What do you mean by distnguishing clients by this object?

And yet my locking works as specified with 5 threads doing random locking and unlocking.
I am confused about that, maybe RMI does map thread to server objects after all.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gennady Shapiro:
I understand that many people have used ReadWriteLock design pattern to implement locking. This pattern relies on all methods by a client to be executed by the same thread...
Surely a pattern doesn't rely on any particular implementation details such as how to identify lock owners. You can implement a ReadWriteLock using an int or an Object as identification, or an iris scan of the person behind the terminal for all I care
ReadWriteLock makes most sense for the database lock, by the way. Arguably it is overkill for the record locks.
- Peter
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Gennady Shapiro:
even if you do have a server-based Connection (or Session) object per client, which I do, there is still no guarantee that this object's methods are called by the same thread. What do you mean by distnguishing clients by this object? [...] I am confused about that, maybe RMI does map thread to server objects after all.
No, RMI doesn't. There is no guarantee that it will always continue to work. There is certainly no guarantee it will work on another Java implementation or version.
If you really have a Connection per client, then you can use those objects to identify client. You can associate a lock with a Connection object. If a lock(record) call comes through and there is an existing lock associated with the same Connection, you know you can ignore it. If Connection.close() is called, you can clean up all the locks associated with that connection. Etc. Etc. All using simple object equality (==).
- Peter
 
Gennady Shapiro
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I may have an explanation on what RMI is doing with regards to threads.
Normally, when you have a socket server it will fork a thread for a client request and make it process all client's requests -- this is a standard way of building network servers. Why does RMI not guarantee the same thread for subsequent calls?
I think the reason might be that RMI has to accomodate HTTP whose stateless nature does not guarantee "keepalive" connections.
Moreover, if you read up on RMI Wire protocol you can see that RMI uses 3 types of lower level protocols: StreamProtocol
,MultiplexProtocol and SingleOpProtocol. The latter is the one designed to operate 1 shot at a time and I suspect is used to run RMI over HTTP and its existance justifies RMI's "no guarantee" of the same thread handling client subsequent requests. In absolute majority of cases RMI systems will use StreamProtocol or MultiplexProtocol that do provide thread consistency. That is why my app works even though RMI spec says it may not.
There is no information regarding these protocol and their thread mapping so I could be wrong about this but it seems reasonable to me.
I erroniously assumed that RMI handler-threads are consistent with clients (which was confirmed by exaustive testing) so I implemented ReadWriteLock that relies on thread consistency, even though as Peter noticed this pattern can be based on anything unique to a client.
As to usefullness of this pattern, I can say that
1. record and database locks use the same code which achieves 100% code reuse
2. this pattern provides virtually no overhead for read operations that are dominating in FBN.
 
Trevor Dunn
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Geez, I am so glad I keep reading this group even though I am finished the cert. I just keep learning stuff. Its wonderful
Trevor
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic