Forums Register Login

The Unreferenced interface and the lock

+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
Do a search on Connection Object, you will find your solution or should I say the removal of a problem with this solution.
Mark
+Pie Number of slices to send: Send
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 ]
+Pie Number of slices to send: Send
"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
+Pie Number of slices to send: Send
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).
+Pie Number of slices to send: Send
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
sunglasses are a type of coolness prosthetic. Check out the sunglasses on this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 499 times.
Similar Threads
RMI Server becoming unreferenced
Implementin Unreferenced
NX:URlyBird 1.3.2/ A question for Database cache.
How to test Network mode?
NX:Client crashed cause deadlock in LockManager
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 04:07:28.