Problem with ConcurrentModificationExc.

Hi,
I tried to solve the problem of stale client locks using a TimerTask inside my LockManager, this task runs every n number of seconds and checks if an acquired lock is held longer than a certain time and if so releases this lock.
I store the record number and the time the lock was acquired in a hashtable. Sometimes when I run my test programms I get java.util.ConcurrentModificationException because the TimerTask uses an iterator to run over the keyset of the hashtable to get the lock times for comparison. Although I use synchronized(hashtable) I sometime get this exception. Any ideas how to solve this problem, or should I just catch the exception and ignore it, although Sun does advice only to use this exception for debugging purposes.
Thanks for your help.
jay
-------
SCJP2

Hi Jay,
I also considered using some kind of timer; but I found it somewhat awkward to implement. Instead I opted for a WeakHashMap, with the identifying object being the key, and the Integer-wrapped record number as value. I found that it worked fine.
In addition I allowed a client to wait for a lock no longer than 10 seconds - then a timeout exception was thrown, and the server told the client that the booking did not work, but that they should re-try a little bit later. (However, I got two points deducted from General Considerations, and another two from server - but I don't know whether it was for this solution or not.)
Hope this helps.

Hi,
thanks for your response, but could you give me a little more details about how this works using a weakhashmap, I also considered this before but a TimerFunctions seemed somehow easier to implement until I noticed the above mentioned problem. Do you use the RMI Unreferenced interface?? Who takes care of the unlocking??
Thanks for your answer.
jay

Hi,
thought about it, I think I understand your solution now. The identifying object is the client connection, right? But how do you pass this key into lock/unlock without modifying the methods signature?
greets
jay

Hi Jay,
I simply called the lock method in the connection object (in my case that was the server-side component of the remote object). I didn't call data.lock (recno), although I did not prevent it.
However, in this forum you find various different solutions to this. Which one you finally submit is rather a question of personal taste than of correctness. I think this is one of those points where the assignment is deliberately vague.
There is also one thing I did not check when I was coding the SCJD: read/write locks (instead of a write-only lock, as I had it). Read/write locks are a fairly standard task in databases.
Hope this helps.
[ November 05, 2002: Message edited by: Mag Hoehme ]