I've been working on my Data class and have two queries;
1) Is it ok to assume that the thread which locks a record will also be the thread that unlocks it?
I've got tests which work when the same thread locks a record then releases it but cannot get a test working when one thread requests the lock and a separate thread releases it. In the latter case, I've got 6 threads requesting 3 locks, and 6 releasing those locks. Occasionally, my LockManager throws a Security Exception (not java.lang, but my own) saying the wrong the given cookie hasn't got the lock I'm trying to release.
2) In my problem description I have the following line;
should the 0x8000 be 0x800? 0x8000 is 32768 while 0x800 is 2048. In Java a short (2 byte number!) can be up-to 32767 (2^15 -1) so 0x8000 cannot be read into 2 bytes! I think 0x800 is the way to go since I've got the data file read in using that.
Have I completely missed something here?
Regards,
John
This message was edited 2 times. Last update was at by John McParland
1/ If you have an interface with a lockCookie, it's easy: the record can only be unlocked with the same lockCookie, generated when locking the record. Your assumption "the thread which locks a record will also be the thread that unlocks it" is wrong, because if you use RMI you will not have that guarantee.
2/ It would be really weird if it is a typo, because these assignments are used for a really long time I think this thread contains valuable information for you.
1) The problem was in my tests, I wasn't sleeping in the releaser threads between attempts to get the cookie from the requester threads. This and simplifying how I set up the test fixed it.
2) Ah I tried some other methods of RandomAccessFile out from what I was already using and it works! A little more in-depth reading of the API was required.
0
I think 
