• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

RMI and threads

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Many of you bring this exerpt from the Sun RMI specification:
3.2 Thread Usage in Remote Method Invocations
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.

Can you please clarify the following:
1. Why should I worry about how RMI executes remote invocations (in separate thread each method or in the same thread)?
2. Why is it important for me to realize that RMI doesn't gurantee mapping between remote invocations and threads?
3. Forgetting how RMI processes method invocations, can i just assume it's analogous to ordinary handler thread-per-client type of deal? (just like with Sockets, where each socket upon client's connection to the server is passed into a newly spawned thread on a server side for further processing) I mean, as far as thread safety goes. In other words, are there any special synchronization mesures i need to take or synchronization techniques I would have done for a socket based solution would suffice for RMI?
The reason i am asking all these, is because i read that remote method invocation behaves differently than local one. This is why i just want to make sure i am not missing an important detail.
thanks.
 
Ranch Hand
Posts: 213
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The reason why that tidbit of information is important is because of the requirements behind locking and unlocking combined with being able to identify a client. So, if RMI guranteed that a thread would be tied to a complete client request, you could use the thread id as that client identifier, but because it doesn't you need a different solution. This is where the factory pattern comes into play.
 
author
Posts: 3252
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by lev grevnin:
1. Why should I worry about how RMI executes remote invocations (in separate thread each method or in the same thread)?

Some try to derive object identity or client identity from the identity of the thread that is executing your code. Max Habibi, who published a book on the subject, is one of them. I believe this to be a mistake, even though (the way Max does it) it happens to work with the current implementation of RMI.

2. Why is it important for me to realize that RMI doesn't gurantee mapping between remote invocations and threads?

It removes any temptation to try to use Thread.currentThread() for the purpose of identifying clients.

3. Forgetting how RMI processes method invocations, can i just assume it's analogous to ordinary handler thread-per-client type of deal? (just like with Sockets, where each socket upon client's connection to the server is passed into a newly spawned thread on a server side for further processing) I mean, as far as thread safety goes.

As far as thread safety goes, yes: making your stuff threadsafe for RMI is no different from making it threadsafe in any other multi-threaded situation. You're not missing anything.
In fact, you just gave a nice illustration of the issue at hand; in your hypothetical Socket implementation, the next time that the same client invokes the same object, you are likely to get a completely different Thread. In my exegesis of the passage you quoted, this is potentially true of RMI as well. No guarantees. Whatsoever.
- Peter
 
lev grevnin
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh, i see. So client ID is the reason why i should be careful about how RMI threads work. That's what i suspected.
By the way, some people insist that the client ID is needed to validate the client in case it misbehaves (doesn't do lock(), process(), unlock() sequence). I totally agree - it's a good way to not trust a client, this make your app more robust. However, i think the primary reason should be the unlock() method, which requires the client to simply exit if he doesn't own the lock. This of course requires some kind of client identification. Don't you guys agree?
 
reply
    Bookmark Topic Watch Topic
  • New Topic