aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S 2.1.1: lock(), delete() and unlock() confusion Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S 2.1.1: lock(), delete() and unlock() confusion" Watch "B&S 2.1.1: lock(), delete() and unlock() confusion" New topic
Author

B&S 2.1.1: lock(), delete() and unlock() confusion

Jarek Losice
Greenhorn

Joined: Nov 07, 2008
Posts: 25
Howdy,

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,

    Jarek.

    Sun Certified Java Programmer for Java 6
    Sun Certified Java Developer
    K. Tsang
    Bartender

    Joined: Sep 13, 2007
    Posts: 2419
        
        7

    Hello there, yes B&S is Bodgitto and Scarpero.

    Regarding the interface, your thinking is correct. From your described scenario, the unlock method will throw RecordNotFoundException. Or does it? Should I say does it have to?

    Do your update and delete methods throw RecordNotFoundException? The idea goes for update and delete methods too.


    K. Tsang JavaRanch SCJP5 SCJD/OCM-JD OCPJP7 OCPWCD5
    Jarek Losice
    Greenhorn

    Joined: Nov 07, 2008
    Posts: 25
    K. Tsang wrote:
    Regarding the interface, your thinking is correct. From your described scenario, the unlock method will throw RecordNotFoundException. Or does it? Should I say does it have to?

    Do your update and delete methods throw RecordNotFoundException? The idea goes for update and delete methods too.


    Could you, please, describe it in more detail?

    Jarek.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: B&S 2.1.1: lock(), delete() and unlock() confusion