Hi. I've never had any problems with RMI. It's always been robust and
performant. You needn't worry about garbage collection, just program as
if there were no network, no remote connection! ( I'm being a little
over simplistic here as all severs can go down and you may want to
report this fact to a user. )
> If I understood what right, the tcp-connection beneath is holded the
> whole time!
> Is that right?
You can set timeouts if you want to connection to go down after a set
period. Otherwise, I believe the connection will be released upon
garbage collection - either the client JVM terminates or the remote
reference is nulled on the client. I have left an RMI connection alive
for days without use, and magically, I call a remote method and
everything continues as expected. I'm not sure oi the connection is
closed after lack of useage and then transparently revived without you
noticing.
A lot of people advocate other remoting technologies such as EJB,
Hessian, Spring Remoting etc. But, I've always found RMI the simplest
approach.
nullstring - 14 Nov 2006 16:13 GMT
Ok, sounds great!
With RMI I only can make one way, from the client to the server and not
the other way around, is that right?
I have datas in a db with are displayed on the clients! But I want the
clients automatically beeing updated! I would implement a simple
socketstream which is used as an controll-channel (like: "hey, i got
new datas, call your getdata()-method" )!
Or does RMI has techniques to do stuff like that?
Is it ok, to use 2-dimensinal Strings (for table-datas) as
parameters/returnvalue?
Thank you very much:-)
Nullstring
Thomas Fritsch - 14 Nov 2006 17:04 GMT
> Ok, sounds great!
>
> With RMI I only can make one way, from the client to the server and not
> the other way around, is that right?
No, you can use it both ways.
The way you know is: The client gets a remote object (i.e. an Object
implementing an interface extended from java.rmi.Remote) from the server
and calls some methods of that object.
The other way is: A client-side object implements a Remote interface and
calls a method (e.g. serverObject.addDatabaseListener(this)) of a
server-side remote object. The server-side object later calls back into
a client-side method (e.g. listener.eventOccured(event)) when some event
has occured.
> I have datas in a db with are displayed on the clients! But I want the
> clients automatically beeing updated! I would implement a simple
[quoted text clipped - 4 lines]
> Is it ok, to use 2-dimensinal Strings (for table-datas) as
> parameters/returnvalue?
Yes, you use any object implementing the Serializable interface.

Signature
Thomas
> Does anybody has experience with Remote Method Invocation?
Yes
> Does it run stable??
Yes although not 100% perfect.
> If I understood what right, the tcp-connection beneath is holded the
> whole time!
No. It is used, then put into a connection pool, where it times out
after 15 seconds if it isn't used again. You can control the timeout.
> In this case I just make a RMI-Object when I need it, otherwise I
> delete the rmi-object from the heap of the client!
The RMI object is in the heap of the server. I don't understand the
question.
> But!! Whats about the Distributed Garbage Collector, I heard about
> problem with it!
It can misfire (trigger prematurely) if there are routers in between the
server and the client which go up and down for minutes at a time. But
you can prevent DGC happening at all by holding static references to
your remote objects in the server JVMs.
> (If I just make a RMI-Object when I need it and destroy it after that I
> have many object, which should be deleted)
I don't know what you mean by RMI-Object if you're talking about
something in the client heap. If you mean a server in a server JVM, yes
you can create and destroy them as often as you like. I have seen a
production system with 50,000 remote objects.
If you have high-availability requirements I believe you should look at
RMI/IIOP, which is much the same thing but using a CORBA ORB as the
runtime system instead of the RMI runtime system.