RMI Basic Concepts 02

[Javini Javono]

Hi,
This next part are some notes; please feel free to correct any
mis-notions, if any, or add new ideas.
A ConnectionFactory might also take constructor arguments
or use overloaded methods:

IndependentConnectionInterface connection = null;
boolean localMode = true or false;
if (localMode) {
   connection = new ConnectionFactory().getInstance(localMode);
} else {
   connection = new ConnectionFactory().getInstance(host, port);  //Networked mode is assumed.
}

"In general, a connection factory method accepts host and port, and returns a
connection."
"In RMI, it would return an object offering services through its methods." And,
as I noted above, this object would also have to have been bound to the RMI
registry.
"Connections support concurrent use." I'm not quite sure what this means, but
it is my assumption that when the client works with a remote object, when
method calls are made on that remote object to the server, from the server's
perspective, that class is treated just like a servlet would be treated: that is:
1. The class could be instantiated by the server any number of times as the
server sees fit,
2. Any instantiated class of this remote class can have any number of threads
running through it simultaneously.
A Java object representing a connection has the following functions: (and,
I quote the following bullet items):
* It encapsulates an open connection.
* It's creation is where client authentication takes place.
* It can specify a unique client identifier.
* It provides a ConnectionMetaData object.
* It supports an optional ExceptionListener object.
Of course, some of these purposes are not required for our exam.
Thanks,
Javini Javono

[George Marinkovich]

Hi Javini,

Originally posted by Javini Javono:
A ConnectionFactory might also take constructor arguments
or use overloaded methods:

IndependentConnectionInterface connection = null;
boolean localMode = true or false;
if (localMode) {
   connection = new ConnectionFactory().getInstance(localMode);
} else {
   connection = new ConnectionFactory().getInstance(host, port);  //Networked mode is assumed.
}

I would suggest that getInstance be called create, that there be only a single create method, and that method should take a mode parameter. What do you think?
We may have different designs, but to my mind each client has its own ConnectionFactory. Depending on the mode passed into the ConnectionFactory either a local or remote implementation of the CommonDatabaseInterface is returned. The remote implementation is obtained using a Naming.lookup call. So the remote implementation of the CommonDatabaseInterface is the only remote object bound in the RMI registry for my design. The local implementation is, of course, local so it does not need to be a remote object nor is it required to be bound in the RMI registry.
I seems to me like you have another layer of indirection in there that I don't really understand. Is there something else lurking in your design that I didn't mention? If so, what purpose does it serve?
Hope this helps,
George

[Javini Javono]

Hi George,
Thanks for your responses. I will get out my toy server
and show you. Perhaps I do have too much indirection.
I'll get out my toy server soon, as I like to go through it
and condense it as much as possible before posting it.
Thanks,
Javini Javono

[Andrew Monkhouse]

Hi Javini,

"Connections support concurrent use." I'm not quite sure what this means ...

I would read this as meaning that the server can have two or more connections, all performing operations simultaneously.
So client A can be reading a record concurrently (at the same time) as client B is locking a record.
Regards, Andrew