The Unreferenced interface and the lock

[Hai Wei]

Hi all
I plan to use unreferenced interface to solve the hanging lock problem (a client hold a lock but for some reason, it can't communicate with RMI server, and this produces a hanging lock other client can't get that lock again).
But after I dig the RMI, I find it is problematic. Say there are two clients, Client A and Client B all communicate with one remote object (The number of reference to the remote object is 2), and Client A holds lock X, then something miserable happens, Client A can't communicate with RMI server, cause Client A can't send back the lease after a while DGC notice the problem and the reference to the remote object is reduced to 1, after that Client B want to hold lock X but it can't cause no one unlock the lock X, the reference to the remote object is never become 0 so the unreferenced interface is useless.
Any suggestions or comments are welcome. And thank you for your advice.
[ October 09, 2002: Message edited by: Hai Wei ]

[Mark Spritzler]

Do a search on Connection Object, you will find your solution or should I say the removal of a problem with this solution.
Mark

[Hai Wei]

Thanks Mark
In the Connection Object design, it makes every Remote Object stateful (the code needs to synchronize Object data between different Remote Objects if these Objects add records to the database. Maybe this assignment don't need this code). In fact, the goal of RMI is make the Remote Object stateless and this structure has better scalability and better performance. I think if the DGC provides some per client state callback (not like Unreferenced interface), the problem may has better solution.
[ October 09, 2002: Message edited by: Hai Wei ]

[Mark Spritzler]

"DGC" What is DGC mean?
For this assignment it really is easier to use the Unreferenced and each Remote Object be used as the ClientID, by having it store the client's lock so that Data class doesn't have too, or the LockManager keeps track of what client has what lock.
Mark

[Hai Wei]

Thanks Mark
The DGC is distributed garbage-collection.
The Connection Object design is a decent way to solve lock, unlock, lock hanging problem. But the deficiency is every Remote Object is stateful. Every client needs one Remote Object. (of course, the remote object pooling can solve some problems).

[Mark Spritzler]

Ah yes, now I see what your point is. Actually there isn't any state in the Remote Object, it just holds a reference to the Data class, but it is unique to every client and remains while the client is there, so that resembles stateful.
However in the client serve world you need this stateful, and trying to make it stateless and pooled could make it faster (should more like it), but it is beyond what the requirements need.
That is one of the big lessons in this assignment is not going beyond the requirements to try and build the Taj Mahal.

Mark