• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
     
    Bartender
    Posts: 3648
    16
    Android Mac OS X Firefox Browser Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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.
     
    Jarek Losice
    Greenhorn
    Posts: 25
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic