Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

About lock cookie generation

 
Edwin Dalorzo
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
  • 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 ]
 
Mihai Radulescu
Ranch Hand
Posts: 918
IntelliJ IDE Java Linux
  • Mark post as helpful
  • send pies
  • 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.
 
Bhavik Patel
Ranch Hand
Posts: 155
  • Mark post as helpful
  • send pies
  • 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..
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Go right ahead, just don't blame us when you get an automatic failure for not meeting the requirements.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic