Fantastic!! My RMI surprised me!!! :confused:

[Peter Kovgan]

Short history:
I builded system like this:
client(thin) take reference on server object using RMI,
RMI registeter process creates instance of SomeBusinessClass, show this instnce via JNDI.(very common)
SomeBusinessClass has Data class as member, and call methods of Data class:
update(), lock()...
I thought every time I will connect from new client to remote, remote will create new instance of SomeBusinessClass, and SomeBusinessClass will create
new instance of Data class, but really this is not right!!!

Only when I bind my Implementator class to JNDI, SomeBusinessClass instance created on server, ONLY 1 instance!!! and only 1 time !!!

Every time I connect from client to remote, I take the same instance for all clients!!!
Vlad, guys, I'm not understand why you talking about
singleton/multiton?
This is singleton by default!!!
Am I right?

[Rick Lu]

Only when I bind my Implementator class to JNDI, SomeBusinessClass instance created on server, ONLY 1 instance!!! and only 1 time !!!

I guessed you didn't use connection factory pattern. That's the way how multiple instance can be created with RMI. Try to search "connection factory", and you will find a whole world of it...
Rick

[Vlad Rabkin]

Hi Peter,
Rick is right.
The object registered with RMI registry (in my design) is connection factory. The connection factory has the method MyRemoteDatabase create().
So, your client connects to the factory. Then it get an RemoteObject. ConnectionFactory is free to decide to create a new MyRemoteDatabase, return the same one (singletone) remote object to be shared by all clients or organize a connection pool with remote object.
Factory pattern has two main advantages:
- the logic of managing remote objects is hidden. You can change it without client even to know about it.
- It erases name space confusion. Only your factory is registered with RMI.
Your other remote objects are not registered with RMI. You can use many different Remote objects without need to register them with RMI. All what you need to provide additional methodin the factory:
MyRemoteHotelDatabase createHotelDB()
MyRemoteFlightDatabase createFlightDB()
and so on...
Best,
Vlad
[ November 02, 2003: Message edited by: Vlad Rabkin ]

[Peter Kovgan]

Thank you Rick,
and thank you Vlad for helpful explanation!!!

[Nicholas Cheung]

I would like to ask, do I really need a connection factory to create different RMI remote objects?
As I cannot find in the assignment that I need to have a connection pool, and Max's example also do not use such approach.
Please advice.
Thanks

[Bill Robertson]

I would like to ask, do I really need a connection factory to create different RMI remote objects?
As I cannot find in the assignment that I need to have a connection pool, and Max's example also do not use such approach.

You don't need one, but it makes life easier and the design is easy to pick up and is well known. Which will make your grader happy. Also, the
connection Factory can hand out local objects along with network objects.

[Paul Tongyoo]

Originally posted by Nicholas Cheung:
I would like to ask, do I really need a connection factory to create different RMI remote objects?

Hi Nicholas--
Does your locking mechanism specify the use of cookies (primitive of type long)? If it doesn't, a connection factory is nice to ensure unique instances of your Data object go out to each client so that you can use such references as keys when you lock your records.
In my specifications, my locking mechanism uses cookies, so I had no need for unique instances of my Data object as I would need to create unique integer keys for my locks anyway. Therefore my implementation has my RMI server dish out the same (Remote)DataAdapter instance to clients; thread-safe functionality is handled by a lower-level, statically referenced DBAccessor object within my Data class. I haven't run into the need for a connection factory yet.
HTH
Regards,
Paul

[Paul Tongyoo]

Scratch that-- I may need a Factory to solve the dropped-clients-after-locking-a-record problem.

[Nicholas Cheung]

Hi Paul,

Does your locking mechanism specify the use of cookies (primitive of type long)? If it doesn't, a connection factory is nice to ensure unique instances of your Data object go out to each client so that you can use such references as keys when you lock your records.

My spec does not specify the cookie in any method calls, but still, I have the following implementation:
DBMain is the interface provided by SUN.
Data is the class that implements the DBMain.
It has a static instance of RandomAccessFile, for each I/O operation, I will synchronize it in order to prevent file corruption or inconsisent read.
In the locking protocol, if a thread wants to lock on recNo X, I add it to the Vector to keep this lock. When the thread releases it, I remove it from the Vector. I saw this approach from Max's book.
DataAdapter calls the methods from Data to perform operations, and then wrap it from String[] to Room object.
DataApapter contains ONLY ONE instance of Data, obtained by

Data.getInstance(String file);

. I know this is one of the hot discussion on Singleton and Multiton, but I really think that, since I synchronized the RAF and I assume there is only 1 database file, thus, even I implement it as multiple instances, it may not be that meaningful.
RemoteServer and LocalServer contains the DataAdapter instance for the client to access.
Any comments for my design?

In my specifications, my locking mechanism uses cookies, so I had no need for unique instances of my Data object as I would need to create unique integer keys for my locks anyway.

I wanna ask for a long time, the 1st 4 bytes of the database file is the MAGIC COOKIE, what is the usage of it? It seems that I havent use it in my implementation.

Therefore my implementation has my RMI server dish out the same (Remote)DataAdapter instance to clients; thread-safe functionality is handled by a lower-level, statically referenced DBAccessor object within my Data class.

Currently, I am doing the same thing as you. But I wanna know, do your 2 classes RemoteDataAdapter and (Local)DataAdapter are exactly the same, except methods in the remote one throws RemoteException, while the local one dont?
I am now thinking of whether this is a good idea, since all codes in them in fact can be totally duplicate, and they cannot implement the same, say, ServerServices interface due to the different Exception thrown.
Thanks for advice.
Nick

[Paul Tongyoo]

Originally posted by Nicholas Cheung:
Currently, I am doing the same thing as you. But I wanna know, do your 2 classes RemoteDataAdapter and (Local)DataAdapter are exactly the same, except methods in the remote one throws RemoteException, while the local one dont?
I am now thinking of whether this is a good idea, since all codes in them in fact can be totally duplicate, and they cannot implement the same, say, ServerServices interface due to the different Exception thrown.

Nick--
You have brought to my attention a significant related issue (problem?) in my design. I would like to describe it here; hopefully ranchers can help answer both our questions.
My GUI layer contains a class that requests an object of type DataClient, which is an interface to the database that matches both my (Local)DataAdapter and RemoteDataAdapter classes. To solve the exception "difference" that Nick mentions above, each operation of my DataClient interface declares that an IOException is thrown from it. This subsequentally forces both my adapters to throw IOException for each operation as well. Now the only difference between my two adapters is that my RemoteDataAdapter operations also throw a RemoteException.
I question this approach since my DataAdapter operations never actually throw IOExceptions, and my RemoteDataAdapter actually only throws subclasses of IOException (RemoteException). But is there another alternative? (This is where our questions may be similar Nick) How else can I represent both adapters in a way that doesn't requiring "unnecessary" exception declarations?

Thanks in advance,
Paul
[ November 21, 2003: Message edited by: Paul Tongyoo ]

[Trym Moeller]

Hi
I would suggest that your gui, doesn't know IOExceptions (which comes from your choice of database implementation (or SUN's) ;-), but only business exceptions. So catch your rmi exceptions handle them and if necessary throw relevant business exceptions. I don't know if this solves your problem, but maybe new ideas arise.
Best regards Trym

[Paul Tongyoo]

Originally posted by Trym Moeller:
Best regards Trym

Hi Trym--
Thank you for your reply-- your suggestion doesn't address the issue i was trying to convey but it is definitely good advice nevertheless.
The question I still have (Nick, have you solved this yet?) is on the "cleanest" way to represent both a local and remote connection to the persistence layer with one interface on client-side (hope this statement isn't more vague than my original ).
Thanks again,
Paul

[Nicholas Cheung]

Hi Paul,

Nick, have you solved this yet?

I still suffering from it. Intentionally, I think the approach work:
I have an empty interface Services, which contains NO methods.
And then I have 2 other interfaces LocalServices and RemoteServices which contain exactly the same methods, but the different is the remote one throws RemoteException while the local one dont.
I do this becos I hope the GUI can have 1 single type of Services.

....
public Services connection;
public Services getConnection(int type) {
    if (type == LOCAL) {
        return new LocalServicesImpl(); //Implements LocalServices
    } else {
        return (Services) Naming.lookup("rmi://localhost:1099", "RemoteServer");
    }
}

However, I suddenly discovered that, if Services is empty, all method calls, like search(), book() cannot be called, as the Services in fact in empty, and the method binding happened during complication time, not runtime.
So, I need to re-think of other similar apporaches X_X"
Andrew gives me some ideas:
NX: Connection problems
However, if I do so, I think it is quite similar to the case we want to avoid. I wish I can try out other methods by the end of this week.
How about you? any progress?
Nick

[Paul Tongyoo]

Originally posted by Nicholas Cheung:
How about you? any progress?

I think i'm just going to stick with what I have now; maybe i can get away with justifying my design in my choices document. I'll post back to this thread if I accidentally trip over a brilliant solution
Regards,
Paul
[ November 27, 2003: Message edited by: Paul Tongyoo ]

[David Chan]

In Max's DVD example, does the server implement as multiple instance or single instance? There is a static Vector variable to keep track of all DVDs that are reserved at any given time, but I do not see any connection factory used in the example (it seems the single instance serves for all client request). Can I say that is single instance and relys on RMI for mutlithreading? If it is single instance server, why he declare the Vector variable as static?

David