Java RMI and Thread Synchronization questions

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 RM开发者_开发问答I 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.

Thank you for your time and answers.

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.

Skeleton:

public class MyRemoteClass {
   public static Object lock = new Object();

   public void doStuff()
   {
       synchronized( lock ) { ... }
   }
}

public class Cleanup {
   public static void doIt()
   {
       synchronized( MyRemoteClass.lock ) { ... }
   }
}

1. 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.

2. 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 skeleton that demonstrates how to achieve this kind of basic synchronization. Since everything is now mutually 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

Object mutex = new Object();

int rmiMethod1() {
    synchronized (mutex) {
        doWhatNeeded1();
    }
}

int rmiMethod2() {
    synchronized (mutex) {
        doWhatNeeded2();
    }
}

// in your cleanup thread
void run() {
    synchronized (mutex) {
        cleanUp();
    }
}

To clarify all this confusion:

1. If you synchronize your remote method implementations only one client can be executing at a time.

2. If you synchronize your cleaner task on the remote object it joins (1).

3. You can't define remote methods as static.

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:

Java RMI and synchronized methods

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).