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

my doubts about RMI

 
Gerald Kou
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From my excercise,I find all the client can only gain one single instance of the remote object
which is binded with JNDI name.Because when I change a object's member(means :is not static
member) of the remote object got from one client,I watched that the same member of the remote
object which I got from another client were also changed.
But when I executed the method of the remote object instance, the result is that executions of
the remote object method in different clients are different threads. why occurs this practise?
If the remote object instance is singeton ,why dis result likes many threads(means: many remote
object instances) run.
digist of my code :
public interface IRemote extends Remote {
void prnStr() throws RemoteException;
void setStr(String str) throws RemoteException;
String testSynchronizedStr() throws RemoteException;
}
class IRemoteImpl extends UnicastRemoteObject implements IRemote {
public static int i = 0;
public int j = 0;
String str;
public void prnStr() {
System.out.println("in IRemoteImpl getStr() i= " + i++);
System.out.println("in IRemoteImpl getStr() j= " + j++);
System.out.println("the obj str is " + str);
}
public synchronized String testSynchronizedStr() {
System.out.println("start: testSynchronizedStr");
long count = 0;
while (true) {
if (count % 10000000 == 0)
System.out.println("now count is " + count);
if (count++ > 150000000l)
break;
}
System.out.println("end: testSynchronizedStr");
return "ok";
}
public void setStr(String str) {
this.str = str;
}
}
public class RemoteServer {
public static void main(String[] args) {
try {
LocateRegistry.createRegistry(1099);
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
String name = "RemoteTest";
IRemoteImpl oneRemoteObj = new IRemoteImpl();
if (oneRemoteObj == null)
throw new Exception("RemoteFactory error");
Naming.rebind(name, oneRemoteObj);
System.out.println("RemoteTest bound");
} catch (Exception e) {
System.err.println("RemoteTest exception: " + e.getMessage());
e.printStackTrace();
}
}
}
public class Client {
public static void main(String[] args) {
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
}
try {
String jndiName = "RemoteTest";
System.out.println("starting...");
IRemote theRemoteObj1 = (IRemote) Naming.lookup(jndiName);
theRemoteObj1.setStr("obj1");
theRemoteObj1.prnStr();
System.out.println("...........");
IRemote theRemoteObj2 = (IRemote) Naming.lookup(jndiName);
theRemoteObj2.setStr("obj2");
theRemoteObj2.prnStr();
theRemoteObj1.prnStr();

System.out.println("########### test synchronized ############");
System.out.println(theRemoteObj1.testSynchronizedStr());
} catch (Exception e) {
e.printStackTrace();
System.out.println("Exception end");
}
}
}
you can start several clients to see the output:
1 the variable "j" is changed by all the clients not by separated clients.
2 testSynchronizedStr() run as in several threads
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Gerald
I think your question is: why does a single instance of an RMI object use different threads on subsequent calls to RMI methods.
I didnt look at your code, because what you described is normal procedure, and because your code was not in a code block. Please put your code inside UBB code blocks so that indenting is preserved.
From the Java Remote Method Invocation Specification:
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.

From the same source, talking about Remote Object Activation:
Distributed object systems are designed to support long-lived persistent objects. Given that these systems will be made up of many thousands (perhaps millions) of such objects, it would be unreasonable for object implementations to become active and remain active, taking up valuable system resources, for indefinite periods of time. In addition, clients need the ability to store persistent references to objects so that communication among objects can be re-established after a system crash, since typically a reference to a distributed object is valid only while the object is active.
Object activation is a mechanism for providing persistent references to objects and managing the execution of object implementations. In RMI, activation allows objects to begin execution on an as-needed basis. When an activatable remote object is accessed (via a method invocation) if that remote object is not currently executing, the system initiates the object's execution inside an appropriate JVM.

Does this answer your question?
Regards, Andrew
 
Gerald Kou
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Andrew !
quote:
---------------------------
I think your question is: why does a single instance of an RMI object use different threads on subsequent calls to RMI methods
---------------------------
It's a exact description of my question!
I had seen " RMI Specification" before. But Now I can't understand the statement "A method dispatched by the RMI runtime to a remote object implementation may or may not execute in a separate thread. " in it.
Why it say "may or may not "? it run in ervery threads or not ?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why it say "may or may not "? it run in ervery threads or not ?
The point is, we don't know, and cannot make any assumptions. The spec authors intentionally made this undefined in order to give greater freedom to RMI implementations to find a strategy that gives best performance in a given situation. One common solution would be to use a thread pool in which most requests are handled by different threads - however threads can be re-used, and so it's always possible that some later request might be handled by the same thread that had handled an earlier request. It's not worth anyone's time to worry about this - just make sure that your program does not make any assumptions about which thread will execute a request. E.g. someone might use Thread.currentThread() to identify the thread that's currently running, which is useful for some things - but if you try to save this in a List or something for comparison with other threads, well, down that road lies madness.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jim is correct: if you need to track who locked a given record then tracking threads is the wrong way to go. IMO, this is an easy mistake to make. I've done it
M
[ June 26, 2003: Message edited by: Max Habibi ]
 
Gerald Kou
Greenhorn
Posts: 14
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you for the descriptions.I gain it.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic