• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Rmi is threadsafe ?

 
James Du
Ranch Hand
Posts: 186
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I saw many posts said that Rmi is threadsafe as compared with Sockets without giving more details.
I wonder why Rmi is threadsafe? in which perspective? Could anyone elaborate it?
Thanks
James
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just that RMI handles threads for you, whereas in Sockets you will have to handle threads yourself. Basically in sockets you will have a listener thread that listens for connections, when one is made it spawns a seperate thread to handle that connection from then on for each connecting client. After a client disconnects you need to handle the thread and clean it up.
That's the difference.
Mark
 
James Du
Ranch Hand
Posts: 186
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Mark,
From what you said, i found the feature has noting to do with "threadsafe", maybe better refer as "automatic threads-handling".
Since what RMI do is make the remote object itself a thread or sth like that, saving the programmers' energy to wrap a thread out of it and clean it up later, and not involving any control of concurrent access to any resource.
Is my understanding sound?
James
 
Ramesh kumaar
Ranch Hand
Posts: 146
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,
Any of u please explain what is mean by threadsafe?
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ramesh,
Let's do this with an example. You have three clients running on different threads. You have one server which has a private int variable called state and public getState and setState methods. If state is initially set at 0, but the three clients do something like call getState and add or subtract something to it and then call setState then what happens when client one calls getState and adds 5 to it but before calling setState, client two calls setState after having added 3? Pretty soon, state will no longer be holding what you would expect. This is called a race condition because the two threads are in a race with each other to modify the data before the other. This scenario is not thread safe. In Java, to make a method thread safe, you add the keyword synchronized to the signature, or alternatively you can synchronize on an Object. When a method or Object is synchronized, only one thread at a time is allowed to access that Object.
Hope this clears it up,
Michael Morris
 
guoyuan zhao
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi,Here is a good introduction to RMI,articlehope it helps!
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
and not involving any control of concurrent access to any resource

Not completely sure what you mean by this part of the sentence.
There are still thread issues you will need to handle, as in the lock and such so that only one client can had a lock on a record. RMI does not handle this kind of thread safety.
Mark
 
James Du
Ranch Hand
Posts: 186
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What i mean is that RMI do nothing to make any resources threadsafe, like some of the methods in the java.util.Collections do.
as in the lock and such so that only one client can had a lock on a record. RMI does not handle this kind of thread safety

Sort of the same meaning with your sentence.
Hope it clear up a bit.
James
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic