Is the RMI registry "process-atomic"?

Question

Hi,
Sorry if this is a really stupid question, and I have really tried to find this out on my own.
When I say "process" I mean Process, as opposed to Thread.
What I mean is, if one Process calls Registry.bind( String, Remote ), can we be sure that another Process which does the same thing one nanosecond later will get an AlreadyBoundException if it calls with the same String?
The context is that up to now I have been starting the RMI Server (only for logging at the mo, these are my first steps) explicitly in a Process. But now I want to move to "lazy" startup of the RMI registry and of the Server... so I would go LoggerInterface.log( bindingName, message ), and if the name "bindingName" is not presently in the registry it will create a new Server, and log the message using it.
More specifically, this is about me trying to automate OpenOffice apps using Java... and it occurs to me that 2 events could indeed happen almost simultaneously, so in fact even explicitly starting up the Server in each handler module might encounter "Process concurrency" problems ... so I need to have an answer to this.
I hope the answer is yes... otherwise I'm going to be a bit flummoxed about how to ensure one doesn't start up one Server Process from one calling Process, and another Server Process from another calling Process.
Thanks

Answer 1

I mean to use rebind() instead of the lookup()/bind() pair. It is atomic.... I understand it is atomic, but my point is that between checking whether you need to rebind (because the bound stub is invalid) and actually doing the rebind there will be an interval. If you systematically use rebind, without a prior check to make sure your Remote is actually attached to an existing Process, every call will cause a new Server Process to be created and then rebound, one after another. Which would be a mess.
I'm going to spend a bit of time looking at your two references... thanks for them.
I have thought of a possible solution involving a sort of lock, but I'm not sure if it works.
1. create a "DummyInterface" extending Remote:
public interface DummyInterface extends Remote {
}2. in the Process + Thread which actually sets up the Registry, bind a DummyInterface
Registry reg = null;
try {
  reg = LocateRegistry.createRegistry( 1099 );
} catch (RemoteException e) {
  return; // is this right? see below...
DummyInterface dummyStub = new DummyInterface(){};
try {
  dummyStub = (DummyInterface) UnicastRemoteObject.exportObject( dummyStub, 0);
} catch (RemoteException e) {
  // TODO sthg
  e.printStackTrace();
try {
  reg.bind( "DummyLockForLoggerServer", dummyStub );
} catch (AlreadyBoundException e) {
  // every Thread in every Process (except the first such) to call "bind" will get here
  return;
} catch (Exception e) {
  // TODO sthg
  e.printStackTrace();
}3.     the first Process + Thread which wants to set up the LoggerServer will have first to unbind the DummyLock.
try {
   reg.unbind( "DummyLockForLoggerServer" );
} catch (AccessException e) {
   // TODO sthg
   e.printStackTrace();
} catch (RemoteException e) {
   // TODO sthg
   e.printStackTrace();
} catch (NotBoundException e) {
  // every Thread in every Process (except the first such) to call "unbind" will get here
  return;
// only one Thread in one Process will ever succeed in getting here
// start the LoggerServer
String qualifiedClassName = ".... rmi.LoggerServer";
String[] a_commandArgs = { "java", qualifiedClassName, "logName" };
Process process = null;
try {
  process = Utils.runSubprocess(a_commandArgs, null, ProcessSettings.getJavaRootDir());
} catch (IOException e) {
   // TODO sthg
   e.printStackTrace();
}... however there seem to be one or two questions about this:
- does reg = LocateRegistry.createRegistry( 1099 ); throw a RemoteException if the Registry is already bound? I don't know and intend to do a few experiments to find this out for myself. But in any event only one Process+Thread can ever bind the dummy lock
- there might be a race condition nonetheless to do with the interval between creating the Registry and binding the dummy lock... during this interval the Registry is established, and the dummylock is not yet set up... but I think this does no harm, as a Process trying to start the LoggerServer during this time will get the "NotBoundException" and simply return (and the calling thread will then sleep for a bit before trying again).