• 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

About lock cookie generation

 
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The lockRecord() method proposed by Sun in the SCJD specification generates a cookie, which is value that represents the lock a client acquires for a particular record.

The application is supposed to provide this value again when the record is to be unlocked.

I have never been very sure about this cookie mechanism, but the Sun specs leaves room for nothing else in this regard.

My point is that I believe I do not need the darn stupid cookie to lock a record. I keep all locks in a HashMap where the key is the record number and the value is WeakReference to the Thread (client) that requested the lock. If a thread dies unexpectedly without first relinquishing the lock I realize of it and make record available again.

So, I was thinking that for the cookie value I could return the hashCode of the thread holding the lock.

When the unlock method is invoked, I should verify that the cookie corresponds with the current Thread hashCode, otherwise I will throw a SecurityException. This check, evidently, is the same as checking that the current thread is equal to thread holding the lock. But the cookie check would help me fail earlier in the method execution, since I do not need to located the lock for the record to perform this check.

I would like to know what you think or if you have better ideas about how to approach to this cookie generation problem.

Thanks in advance
[ September 18, 2006: Message edited by: Edwin Dalorzo ]
 
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Edwin,
Two points
1.even if you like it or not you must follw the sun specs.
2.If you have in plan to use RMI you have no control over the threads on the server side, so you can not idetify the clients using the thread, this thema was often dissused here.

Regareds M.
 
Ranch Hand
Posts: 155
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
not thread object's hashcode but how about my implementation class (Which is being returned for each client ..something like new DatabaseImpl())'s hashcode as cookie..which will be returned as long value( hashCode() returns int but we can store it as long and return ) ..any lights on this mechanism..
 
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Go right ahead, just don't blame us when you get an automatic failure for not meeting the requirements.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic