• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: URLyBird - lock-delete-unlock and RecordNotFoundException

 
Lanuk Jajab
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I have seen plenty of discussions around LockManager and lock/unlock strategies, however I still have some lingering doubts. My version of the URLyBird assignment implements lock/unlock using cookies. Now, as per my DB interface definition, the unlock method can throw RecordNotFoundException. That being said, in a situation where a client calls lock-delete-unlock in sequence will always get a RecordNotFoundException when performing the unlock. This has been documented by me in the design document. However, when playing around with my test thread I've come up with a situation that essentially hangs my implementation and I need some ideas on how to resolve it.
Imagine the following scenario, I have a user that performs the following operations :
(Where X is a valid Record)
Lock Record X ---> Success
Delete Record X ---> Success
Unlock Record X ---> Failure (RecordNotFoundException) by definition
(Note that since I check for validity of the record before I do anything else in Unlock, my record number for all intents and purposes is still locked at this time)
A different client or same attempts to insert a new record. My application tries to determine if there are any deleted records that it could potentially replace and thus save space. So, client gets the Record Number (X) which had just earlier been deleted.
Client inserts new Record X (success)
Another client attempts to Update Record X so does the following :
Lock Record X ---> (Wait forever) as Record X never got unlocked.
I realize that this may be beyond the requirements for the exam, but it still has me a little concerned.
What could be the possible solutions in this case?
a) When attempting to insert a new record , test to see if New Record Position exists in Map of Locked Records, and if so remove.
b) In Unlock method, go ahead and remove record from Locked Records, and then throw RecordNotFoundException in a lock-delete-unlock scenario, so that this Thread starve situation never arises?
c) Document current situation and hope for the best?
Any ideas or comments would be greatly appreciated!
Thanks
Lanuk.
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Lanuk,
You wrote:

Imagine the following scenario, I have a user that performs the following operations :
(Where X is a valid Record)
Lock Record X ---> Success
Delete Record X ---> Success
Unlock Record X ---> Failure (RecordNotFoundException) by definition
(Note that since I check for validity of the record before I do anything else in Unlock, my record number for all intents and purposes is still locked at this time)
A different client or same attempts to insert a new record. My application tries to determine if there are any deleted records that it could potentially replace and thus save space. So, client gets the Record Number (X) which had just earlier been deleted.
Client inserts new Record X (success)
Another client attempts to Update Record X so does the following :
Lock Record X ---> (Wait forever) as Record X never got unlocked.

This scenario has been discussed and is being discussed in a couple of threads that I am participating in. You are right, the unlock method will throw the RecordNotFoundException for sure in this situation. I was planning on documenting it and leave it at that. I guess that can be done at this point is to test within the unlock method if the record has been "actually" deleted and if that is true then unlock it before throwing the RecordNotFoundException? I would love to hear what others have to say here.
Regards.
Bharat
 
Lanuk Jajab
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Bharat,
Like you have pointed out, I did document that in a lock-delete-unlock scenario, the unlock method always throws RecordNotFoundException. I am fine with that.
What concerns me is the cascade effect this logic has on potentially other operations that may happen in succession similar to the one I outlined in my earlier message primarily due to the fact that if you follow Sun's documentation to the letter, you would never be able to unlock a deleted record.
Although it could be argued that what Sun requires is that you throw a RecordNotFoundException in unlock for a deleted record, but there's nothing stopping you from unlocking the record regardless (so long as the cookie matches) and then throwing the exception. Although this seems rather pointless, because the whole idea of throwing an exception is for you to show an exception condition to the client.
I would love to get any feedback on the right strategy to solve this particular problem.
Thanks,
- Lanuk.
 
Vlad Rabkin
Ranch Hand
Posts: 555
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Bjarat and Lanuk,
To avoid the prblem my delete method unlock the record itself, so the client has only to tak 2 steps:
-lock
-delete
and the record will be unlocked automatically. Of course, I will document this.
Best,
Vlad
 
Bharat Ruparel
Ranch Hand
Posts: 493
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey Vlad,
That is what I will do too. Smart thinking!
Regards.
Bharat
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic