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.
I would recommend against having a thread kill off locks that have been hanging around too long. Not only the instructions do not require this, but my reading of the instructions would lead me to believe that the lock would remain valid for as long as my client application wanted it to stay valid.
You may wish to look at the recent topics talking about RMI Connection Factories, and using this in conjunction with either the Unreferenced interface or a WeakHashMap to do dead client cleanups.
If you do want to have a timeout, then you are going to have to have some way of storing the time the lock was granted with the lock itself - possibly have a lock object which holds these details.
Regards, Andrew [ July 06, 2004: Message edited by: Andrew Monkhouse ]
I thought over and over, and the conclusion is that I never use dead lock cleaner.
Because my design adopt the optimistic lock, i.e. user can't lock a record when selecting a data row in JTable. for update functionality, I envelop the update() and lock() given by instruction, just provide client program a method executeUpdate() that refer to update() and lock(), and executeUpdate() run at server side, so never occur dead lock situation.
and I don't use cookie, but I read some guideline book, most of them recommend to use cookie to uniquely identify the locking thread, I am not sure my design at this aspect.
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