• 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

locking and RecordNotFoundException

 
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello,
in many posts I see the following implementation style:

I'm sure that many developers use this style not only in lock, but in delete(), update() etc. But I'm not sure about this issue:

As the result caller gets RecordNotLockedException(or no exception - depends on implementation style). But the record is already deleted, so RecordNotFoundException had to be thrown.
Possible solutions: lock entire database, lock concrete record, leave as is. Any comments?
 
Ranch Hand
Posts: 697
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Gytis

Originally posted by Gytis Jakutonis:
Hello,
in many posts I see the following implementation style:

I'm sure that many developers use this style not only in lock, but in delete(), update() etc. But I'm not sure about this issue:

As the result caller gets RecordNotLockedException(or no exception - depends on implementation style). But the record is already deleted, so RecordNotFoundException had to be thrown.
Possible solutions: lock entire database, lock concrete record, leave as is. Any comments?


I think & remember the sequence you mentioned is followed in lock method and not in unlock. The reason is we check if record is valid or not first in lock and if record is valid, we check if record is locked or not. If record is locked, wait for lock to release. If record is not valid, throw RNFE. So the sequence should be followed in lock method.
If your sequence is correct, I am not sure of why there is check for isLocked or isValid in unlock?
GoodLuck.
 
Gytis Jakutonis
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


If your sequence is correct, I am not sure of why there is check for isLocked or isValid in unlock?


unlock() throws RecordNotfoundException, so we need to call isValid() or smth like that. As for isLocked() - seems obvious that only lock owner can remove it.
 
Gytis Jakutonis
Ranch Hand
Posts: 76
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The problem is how should we interpret following statements:
  • Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file
  • Locks a record so that it can only be updated or deleted by this client.


  • So what should happen, if client breaks locking policy(second statement), e.g. tries to unlock record without owning a lock(or update or delete record, whatever). The simplies(considering concurency issues) solution is to call isLocked() at the begining of unlock(), delete(), update() and throw unchecked exception. But how does SUN interpret the folowing situation: client has no lock, and record does not exist, and client tries to delete(), update() or unlock() the record? Does SUN expect RecordNotFoundException or can we throw some sort of RecordNotLockedException(unchecked), since locking policy was broken?
     
    Satish Avadhanam
    Ranch Hand
    Posts: 697
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Gytis

    Originally posted by Gytis Jakutonis:
    The problem is how should we interpret following statements:

  • Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file
  • Locks a record so that it can only be updated or deleted by this client.


  • So what should happen, if client breaks locking policy(second statement), e.g. tries to unlock record without owning a lock(or update or delete record, whatever).
    If client breaks locking policy then you should document in your design decisions that on such a condition(client breaking policy), application will not run as expected. It is beyond the scope of project to deal with issues as client breaking some afore said rules. Also many people write in their design choices that if client does not follow any policy like locking or any other policies mentioned in their design documents, then it is not guarenteed that application runs properly as expected. And they passed with good scores too.
    Good Luck.

     
    Gytis Jakutonis
    Ranch Hand
    Posts: 76
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Satich,
    thanks for your reply. While waiting for an answer I came to the same conclusion, so you post removed all doubts. Maybe I can solve in the same fasion(by documenting) another issue: isLocked(recNo) can return false(instead of throwing RNFE) then the record is deleted while isLocked() result reaches a client(because that client does not own a lock, so another client can delete the record at any time). And vice versa - RNFE can be thrown but at the time it is catched, record may become valid(i.e. reused by create(..)). Should I leave implementation as is and just document these options, or maybe there are some other solutions to these issues? Thanks.
     
    Satish Avadhanam
    Ranch Hand
    Posts: 697
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Hi Gytis

    Originally posted by Gytis Jakutonis:
    Hi Satich,
    thanks for your reply. While waiting for an answer I came to the same conclusion, so you post removed all doubts. Maybe I can solve in the same fasion(by documenting) another issue: isLocked(recNo) can return false(instead of throwing RNFE) then the record is deleted while isLocked() result reaches a client(because that client does not own a lock, so another client can delete the record at any time).

    I really do not understand what's going on here. If isLocked(recNo) is given in instructions its OK. What I do not understand is after calling isValid() to check whether record is valid or not, then why is isLocked() throwing RNFE? My understanding is that isLocked() only checks if the record is locked or not. If this is the given signature then I might be wrong as I do not have any methods of that sort.
    Anyway coming to the point in question. The sequence you mentioned above is not clear to me. Sorry about that. Here's what I think you were saying:


    And vice versa - RNFE can be thrown but at the time it is catched, record may become valid(i.e. reused by create(..)). Should I leave implementation as is and just document these options, or maybe there are some other solutions to these issues? Thanks.
    [/qb]
    This is OK. For example:

     
    Think of how stupid the average person is. And how half of them are stupider than that. But who reads this tiny ad?
    a bit of art, as a gift, the permaculture playing cards
    https://gardener-gift.com
    reply
      Bookmark Topic Watch Topic
    • New Topic