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 ]