In Denny's DVD project, when one client starts, it does the following:
1. In GuiController , sample.remote.DvdConnector.getRemote(....) return a DBClient connection object.
1.1 Underneath the hood, there is a DvdDatabaserFactoryImpl that creates new DvdDatabaseImp();
(The code is in DvdConnector getRemote method)
1.2 Therefore DBClient connection refers to this DvdDatabaseImpl();
1.3 When the DvdDatabaseImp is created, it creates a new DvdDatabase() object;
(The code is in DvdDatabaseImpl constructor).
So, each client has its own connection and its own DvdDatabase object (facade).
Multiple clients will have multiple facade.
What happens if I modify the DvdConnector's getRemote method so that only one DvdDatabase object is used?
I use RmiNoFactoryExample as a reference
In this case, all clients will share the same DvdDatabaseRemote object, which is actually refering to a DvdDatabaseImp object, which
has a DvdDatabase.
In the other words, all clients will use the same DvdDatabase facade.
I think it is OK use to multiple clients to use multiple facade or multiple client to use a single facade because DvdDatabase has a singleton ReserveManager
that will do the locking.
In the exam, which approach I should go for? Multiple client, multiple facade ? Or, multiple client, single facade?
But if you use only one DvdDatabase facade for each connected client, how can you identify the owner for a logical lock?
Isn't it supposed to have some way to identify which client has reserved a DVD record, so that only he (i.e the client) can release it?
The interface provided in Denny's DVD expects that the client should lock a DVD record, modify it, submit the modified record to the server and after then he should release the lock on the record.
There are several ways to identify the client. If you use just one DvdDatabase instance for all connected clients you need of course some way to identify each client. Perhaps an extra method to set the client id before calling locking, updating and releasing a DVD record. Maybe some methods have the clientId as a parameter (in the actual assignment some interfaces do have a lockCookie which uniquely identifies a client).
The most important thing to know about an RMI solution is that you can't rely on the thread id as a unique identifier of the client, because of RMI does reuse threads and thus requests from different clients can be handled by same thread.
Joined: May 09, 2008
Yes, sure, thanks Roel!
I didn't applied for the exam yet, I am still preparing for it