RMI Basic Concepts 03

[Javini Javono]

Hi,
This question concerns specifying a unique client identifier "the easy
way." By that, I mean such as assigning each client a unique Java
long number. Any code examples are not meant to be production quality.
Let us assume that the software will not address multiple database
file tables (as it is assumed that appropriate changes could be made
to handle this case).
We will define the following three remote objects which, ultimately,
directly or indirectly, implement the following interfaces:

IndependentConnectionInterface connectionImpl
IndependentDataInterface dataImpl
IndependentIdInterface idImpl

The above three objects would be in the RMI registry, probably placed
there by the server application which is a separate application.
The client-side code looks something like this:

IndependentConnectionInterface connection = new ConnectionFactory(remoteMode = true).getConnection(host, port);
IndependentIdInterface id = connection.getId();
IndependentDataInterface data = connection.getData();
//Now use data to read the 5th record from the database.  We won't
//worry about storing the results of the call.
intrecordNumber = 5 - 1;
//The uniqueClientId which will be passed as a long to lock
//and unlock is obtained from the id object.
long  uniqueClientId = id.toLong();
data.lock(uniqueClientId, recordNumber);
data.read(recordNumber);
data.unlock(uniqueClientId, recordNumber);

I assume the above is conceptually correct?
Now the only thing I didn't understand in some of the posts is why
people were thinking about using random numbers.
I don't think we need to worry about speed issues when the unique
ID is created on the server. Thus, the following server code,
should not lose any points due to its lack of concurrency:

//Important note:  this is not production quality code, for I have
//read somewhere that there is some difficult issue that one can
//sometimes run into concerning static values and whether the class
//was fully set up.  But, this code gives the basic idea.
public class IdImpl extends Object implements Serializable {
   static long id = 0;
   public idImpl() {
      bumpId();
   }
   private static synchronized bumpId() {
      id++;
   }
   public long toLong() {
      return id;
   }
}

And the server's connectionImpl might look something like this:

public class ConnectionImpl ... {
   //...
   
   public IndependentIdInterface getId() {
      return new IdImpl();
   }
   
   //...
}

All in all, giving each client a unique ID, as long as that darned
client doesn't call connection.getId() twice, seems relatively
straightforward.
The above code is conceptual, it does not pretend to deal with the
intricacies of how you actually go about setting up a remote object
and how you set up the hierarchies of interfaces and the like, but
hopefully I have expressed myself clearly enough.
So, the above is a question, in that it is what I assert to be
true, but would appreciate correction if it is incorrect in some
fundamental way.
Thanks,
Javini Javono
[ February 05, 2004: Message edited by: Javini Javono ]

[George Marinkovich]

Hi Javini,

Originally posted by Javini Javono:
This question concerns specifying a unique client identifier "the easy
way."
...
We will define the following three remote objects which, ultimately,
directly or indirectly, implement the following interfaces:

IndependentConnectionInterface connectionImpl
IndependentDataInterface dataImpl
IndependentIdInterface idImpl

The above three objects would be in the RMI registry, probably placed
there by the server application which is a separate application.

There used to be a TV show called "Name That Tune." On this show the contestants would compete against each other to name a particular tune in the fewest number of notes. The contestant would say: "I can name that tune in 5 notes." Another would say: "I can name that tune in 4 notes." And so on. Whoever bid the fewest number of notes got the first chance to "Name That Tune," and if they were correct they won.
In that spirit I would say I think you can accomplish your goal with only one interface and therefore only one remote object need be placed in the RMI registry. I would go with IndependentDataInterface.
Let's say the IndependentDataInterface has all the database operations required by the Sun-supplied interface. Let's further assume that it has the following method:

    long getClientId();

Then the client-side code might look something like this:

IndependentDataInterface data = connection.getData();
//Now use data to read the 5th record from the database.  We won't
//worry about storing the results of the call.
intrecordNumber = 5 - 1;
//The uniqueClientId which will be passed as a long to lock
//and unlock is obtained from the id object.
long  uniqueClientId = data.getClientId();
data.lock(uniqueClientId, recordNumber);
data.read(recordNumber);
data.unlock(uniqueClientId, recordNumber);

So, what do you think? Can you name that tune using only one interface and one remote object?
Hope this helps,
George

[Javini Javono]

Hi George,
Here's a re-write as you requested using one remote interface.
Thanks for your advice.
I'll skip the connection factory for now (but, when I redo
my toy server, I'll remember to do the connection factory
not as a remote object).
Client Side (pretty much how you gave it above):

IndependentDataInterface   data = null;
data = (IndependentDataInterface) Naming.lookup(url + "RmiBoundDataImpl");
integer   recordNumber = 5 - 1;  //Read 5th record.
long      uniqueClientId = data.getClientId();
data.lock(uniqueClientId, recordNumber);
data.read(recordNumber);
data.unlock(uniqueClientId, recordNumber);

Server side:

public class DataImpl ... {
   
   //...
   
   public long getClientId() {
      return Id.newIdToLong();
   }
   
   //...
}
class Id extends Object {
   private static long id = 0;
   private static void bumpId() {
      id++;
   }
   public static synchronized long newIdToLong() {
      bumpId();
      return id;
   }
}

Thanks,
Javini Javono