I actually have two questions about Java RMI and thread synchronization:

1) If I implement my RMI remote methods as synchronized, are they guaranteed to be mutually exclusive? I need to make sure that no two of my RMI methods (methods offered to clients) execute at the same time.

2) I have a method that the server executes periodically. It is used to do cleanups. I have to make sure that this particular method does not execute when there is any RMI method being run/used by remote clients. Also, when that method is running, RMI calls shouldn't be possible. I.e. Clients must wait. Any idea how I can do that? I have read about Locks, but I do not know how to use them in this scenario.

I have considered implementing RMI methods as static and including that cleanup method inside the RMI interface, but it does not seem to be an elegant way of solving the problem.

I have also written the cleanup method inside the RMI interface as synchronized. When I ran it for testing, there did not seem to be collisions between methods, but I cannot be sure.

4 Answers
4

1) If I implement my RMI remote
methods as synchronized, are they
guaranteed to be mutually exclusive? I
need to make sure that no two of my
RMI methods (methods offered to
clients) execute at the same time.

RMI does not provide such guarantee on its own (unlike EJB) and two calls on the same remote object may be executed concurrently unless you implement some synchronization. Your approach is correct, and synchronizing all methods will indeed ensure that no two of them run at the same time on the same object. Note: The keyword synchronized alone is equivalent to synchronized( this ).

2) I have a method that the server
executes periodically. It is used to
do cleanups. I have to make sure that
this particular method does not
execute when there is any RMI method
being run/used by remote clients.

If the cleanup job is in another class, you will need to define a lock that you will share between the remote object and the cleanup job. In the remote object, define an instance variable that you will use as a lock.

protected Object lock = new Object();

By convention, people use an Object for this purpose. Then you need to grab the lock in your periodic job with synchronized( remoteObj.lock ) { ... }, assuming it's in the same package.

The other methods in the remote object will need to be synchronized the same way (synchronized alone is not enough), so that remote method calls and periodic job are both exclusive.

I have considered implementing RMI
methods as static and including that
cleanup method inside the RMI
interface, but it does not seem to be
an elegant way of solving the problem.

I have also written the cleanup method
inside the RMI interface as
synchronized. When I ran it for
testing, there did not seem to be
collisions between methods, but I
cannot be sure.

If I understand well, you would like to have the cleanup logic be a static method? A static method with synchronized alone grabs a lock on the class. A "regular" method with synchronized grabs a lock on the object instance. These are not the same implicit locks!

But if you have only one remote object instantiated, you can make the lock static (That's the same as locking on the class, but is a bit cleaner). The cleanup code can then be static as well and be in the same class as the remote object or not.

I don't know about the downvote. Anyway, can you please elaborate more on the locking mechanism? I see a reference in another reply, and I didn't understand all of it. If I implement the lock in a remote object, how can I acquire the lock from a Server local object? Something like a public static variable in the remote object? Or if you could provide any links/tutorials/code snippets, it'd be ok too. Thanks. :)
–
Inf.SFeb 16 '10 at 22:07

'RMI does not provide such guarantee.' True but that wasn't the question. He is synchronizing. Synchronizing does provide that guarantee.
–
EJPFeb 16 '10 at 23:10

And synchronizing all the methods would work just as well as a lock object on the evidence we've been given.
–
EJPFeb 17 '10 at 6:57

That is what I need to confirm EJP. If I implement all the methods in the RMI interface as synchronized, can I be sure no two of them are going to run at the same time at any moment?
–
Inf.SFeb 17 '10 at 7:34

For each call from a RMI client the RMI server will execute the call in a new thread. You only need to synchronize access to shared objects.

Another thread or timer will not stop your server from accepting calls from the client side. This needs synchronization, the best practice depends on how long the cleanup job runs can it be interrupted, or would it be possible to put the requests in a queue etc.
The easiest way would be to let the RMI methods wait for the lock as already described by ewernli.

EDIT: According to your comment, a skelleton that demonstrates how to achieve this kind of basic synchronization. Since everything is now mutual exclusive, you can't expect high performance with multiple clients involved. Anyway this would cover your requirements. (I hope). If your project grows you should read the Concurrency Tutorial

I know that RMI executes new calls in new threads. The problem is that I don't want two remote methods to run at the same time. This includes the same method not being called more than once. I thought simply using synchronized methods would solve the problem. I read that off some forum through searching Google. Is it a certainty that RMI will ignore the synchronized directive and proceed to run remote methods concurrently?
–
Inf.SFeb 16 '10 at 22:10

Thank for you for this very illustrative example. About the mutex Object. Synchronized(mutex): what does this line do? Does it acquire the provided lock for the object? Also why not use a Lock object as shown in the Concurrency tutorial? Thanks.
–
Inf.SFeb 17 '10 at 7:36

synchronized (mutex) tries to accuire a so called monitor which ensures that only one thread enters the critical (protected) section. If another thread has already entered the critical section all others have to wait until it leaves the synchronized {} block. The possible ways to do this are described in the tutorial. This one is my personal preference.
–
stackerFeb 17 '10 at 9:44

(1) is not correct. First, the threading behaviour of RMI is deliberately and explicitly not specified. Second, in the Sun implementation, connection pooling can mean that successive calls from the same client are executed in the same thread. The code shown is equivalent to just synchronising the methods concerned, which would be a lot simpler.
–
EJPDec 4 '12 at 19:45

@EJP Hm, I read this again after years. I probably tried to describe the behaviour I observed in a system I had to maintain from time to time.
–
stackerDec 4 '12 at 22:09

You must keep in mind that RMI creates the illusion of a "remote object", but in reality there are no less than three objects: the local stub, the remote skeleton and the actual remote object. As a design trade-off this illusion is not complete and is locking only the local stub. There is no synchronization across the network. Search the internet for RMI+stub+synchronized and you will find plenty of explanations, like for instance this one:

So you need to implement some kind of non-RMI, purely server-side synchronization yourself. Then you can invoke this pure server-side locks from your remote methods; but you need the additional level of indirection.

To test your code the easiest is to pause your threads under a good debugger like Eclipse. Eclipse will clearly show you which paused thread is holding which lock blocking which other thread(s).