1. does the B&S is for Bodgitto and Scarpero?, just to make sure ;)
2. If so, then I've got a problem with a DB interface
(this is for 2.1.1 version)
the lock method says: "If the specified record is already locked by a different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked."
My question is: should I assume, that the delete method should release the lock assigned to lockCookie gained by calling a lock() ?
The problem scenario:
client A locks a record with id 1
client B tries to lock a record with id 1, but since it's already locked it waits until someone (A in this case) will release the lock. This is exactly as said on the lock() method from DB interface
client A deletes a record with id 1
What do we have now:
client B is still waiting on record's 1 lock, because no one unlocked him
client A can try to unlock record 1 with method unlock(), but since the record is deleted, the unlock() method should throw a RecordNotFoundException in this case. So client A is unable to release the lock on the deleted record - which leads to a starvation of client B.
What I can try to do in this situation is:
assume that the delete() method releases the lock acquired by lock(), which causes that after record deletion all clients waiting (on lock()) will be awakened and fed with RecordNotFoundException. Such a behavior will prevent us from client starvation.
Allow a unlock() method to operate on deleted records - which is, in my opinion a interface contract violation, because the unlock() method has a "throws RecordNotFoundException which point that such an exception should be thrown if the requested record does not exist.
Am I missing something? I 'm not sure, but it seems that the only sane solution here is to assume, that with the deletion of a record, record lock is being released.
What do you think?
Thanks for any ideas on this,
Sun Certified Java Programmer for Java 6
Sun Certified Java Developer