• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Problem with ConcurrentModificationExc.

 
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
jay denzel
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
jay denzel
Ranch Hand
Posts: 57
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Mag Hoehme
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic