This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Hi. Ranchers, I let my RemoteObject to implement the Unreferenced interface to handle with the unexpectly abort client. but I have a question about how to use such interface in my remote object.
My first thought about it is simple :
I think it is absolutely wrong under such scenario, since the unreference does not take effect immediately and we surely have only one RemoteObject, during this time. someother client may lock on other records, When performing the unreferenced, we may work on the incorrect record number and cookie.
Then I improved it as
There are still some problems. maybe when we are executing the unreference, there is a client who are holding a lock and doing the update action, then we may wrongly release his lock.
I can not figure out a good enough way to handle this. can any one help me on this. thx in advance. [ May 02, 2005: Message edited by: Zee Ho ]
SCJP 1.4<br />SCWCD 1.3<br />SCJD<br />SCBCD<br />IBM Xml Cert in progress
I also am having some questions about implementing the Unreferenced interface. But I don't know much about RMI. This is straight from the JDK 1.4.2 API doc for the Unreferenced interface:
Called by the RMI runtime sometime after the runtime determines that the reference list, the list of clients referencing the remote object, becomes empty.
That sounds like it means than only after ALL clients have dropped their connections to the server does the Unreferenced interface get executed by RMI - and at that within some unpredictable time frame. So if only 1 client drops his connection to the server, the Unreferenced interface does not get invoked?
Frans Janssen actually had a good suggestion in another thread that I am using. Simply put a timeout for the wait period of the record lock. When the sleeping thread awakens, it is either because of notification from another thread (which held a previous lock), or because of timeout. If it occurs due to timeout, then force an unlock by the newly awakened thread. I use a timeout of 30 seconds - no record lock should take longer than that for this assignment.
The only problem with this approach is that the specs for my assignment say that the lock should be held until the locked record is made available by the locking client. So if you force an unlock due to timeout, it's not really being made available by the locking client - it's being made available forceably by the waiting client. However, the word "must" was not used in my specs to specify this criteria, so perhaps I can justify this approach in my choices document.
Joined: Jul 20, 2004
Yes, one of my design is to develop a class named LockCookie which encapsulate the cookie number and the time the cookie created. Anytime when user try to lock on a record, I will check whether the record is locked and whether the time expire. I think it is also a way to resovle it. But I really want to know what is the way to implement the Unreferenced.
Joined: Jul 20, 2004
Maybe I got it, I think my second way may be the proper one except chaning the Hashmap to Hashtable to avoid the concurrent accessing. Since the unreferenced will be executed only after ALL client disconnect the server. Then all the record hold in the Hashtable need to be cleaned and surely there's no such problem mentioned in the first posting. since there is no more client in the application.
But it makes me think about another problem. The timer became necessary since in this way, if there's always some clients connect to the system, then the stale record will never be cleaned, right? do we need to consider this? or it is beyond the exam.
[ May 02, 2005: Message edited by: Zee Ho ] [ May 02, 2005: Message edited by: Zee Ho ]
Joined: Apr 19, 2005
Actually, nowhere in the specs for my assignment does it say that you must account for client's dropping out while locking records. This is something that everyone is concerned with - more so from a real world perspective - but I would recommend going with the most simple solution. I'm not implementing the Unreferenced interface, unless I can learn more about how it is supposed to be used. I am just going with a simple timeout option for the locking mechanism. Remember, you can justify your decisions in your choices doc. But I would not spend too much time on trying to make an extravagant solution work - it could backfire on you in the end.
Unreferenced can only be used for your RMI solution if, and only if, your server issues some sort of DBConnection object to every client (meaning, unique to every client). Unreferenced takes over only when there are no more references to the remote object. Be noted, though, binding to the registry counts as 1 reference.
In my opinion, using timed locks is a little overkill. Unreferenced is much easier. But after all, like I said, it depends on how you design your application architecture.
Current Status:<br /> <br />SCJP 1.4<br />SCJD (in progress)
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com