This week's book giveaway is in the Cloud forum.
We're giving away four copies of The Business Blockchain and have William Mougayar on-line!
See this thread for details.
Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Lock/Unlock on a Delete with respect to the "RecordNotFoundException"

 
Matt Lobo
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I have a question regarding the expected results when a record is locked, deleted, and unlocked.

A record needs to be locked before its deleted. Once the record is deleted, the unlock should be called to release the lock on that record, but the instructions state that the "RecordNotFoundException" should be thrown when a record no longer exists. So in this situation, won't the unlock always throw an exception? And if so, is the lock ever really released?

Up until a few days ago, my implementation of the lock manager never actually threw those exceptions because its a logical lock on just an object (being an integer). So theres actually no tie to that and the record. I was fine with this but I dont konw how picky the grading will be if a record that doesn't exists is 'locked.'

Just wondering how other people handled this.

Thanks~
//Matt
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy, Matt!

A record needs to be locked before its deleted. Once the record is deleted, the unlock should be called to release the lock on that record, but the instructions state that the "RecordNotFoundException" should be thrown when a record no longer exists. So in this situation, won't the unlock always throw an exception? And if so, is the lock ever really released?


Very well observed, champ! What you can do is not throw RecordNotFoundException. You can only verify if the client trying to unlock the record is the same client that locked it in the first place. If this is true, then you unlock it. If the record wasn't locked, or if the record was locked by another client, then you can throw IllegalStateException. You can use a Map<Integer, Long> to keep track of the locked records, where the key is the record number, and the value is the id of the client who locked it, and then you use it to make these verifications.
 
Matt Lobo
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the reply!

After reviewing my instructions more carefully, I see that my assignment states: "Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file."

But we all know that: "Where this document uses the word "must" an absolute requirement is being described."

So I guess technically if I don't throw the exception in this case I won't get an automatic failure because the previous statement says that I "should" and not that I "must."

This will definitely be something I add to my choices.txt file.
 
martin naughton
Ranch Hand
Posts: 30
Debian MyEclipse IDE VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hey Matt Lobo,
In my implementation i have a map that keeps track of what is locked. before i lock a record i check that it exists. if it doesnt then throw a exception.

For unlock then i check that the record exists in the lock map. it it does not exist then i throw a record not found. This is incase some how some other another thread removed it from the map. This is a great way to know if your locking works. you should never get unlock exception. if you do then the implementation does not work. happened to me.


Regards
martin
 
Matt Lobo
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the replies.

Im not sure about everyone elses instructions for the assignment but I have to think they are similar about this. As I said earlier, mine specifically states that if a record does not exist, the RecordNotFoundException should be thrown for the unlock method.

This problem is regardless of underlying implementation of your lock management, because I too have a cache of locks and owners so i know whats locked and what isn't.

What I was trying to say was in a typical delete function, let's say of record 5... a service level class would call:

1.) dbMain.lock(5)
2.) dbMain.delete(5)
3.) dbMain.unlock(5)

After step (2), record 5 is marked as a free space in the db file and considered "deleted". To the service, it doesn't exist in persistence anymore. Then at step 3, following the instructions of the assignment, we really should be throwing a "RecordNotFoundException" here because that record doesn't exist. At this point, I still have the lock recorded in my lock cache, but it doesn't change the fact that the record is gone.

The best thing I think we can do is if a unlock is invoked on a record that previously existed, and the one unlocking is the owner of said lock, then I won't throw the exception because the owner of the lock had to delete the record so they hopefully knew what they were doing.

Thanks again for the help,
Matt
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Matt,

In my opinion only the lock-method should throw a RecordNotFoundException, the update, delete and unlock methods shouldn't. When a record is successfully locked, it can't magically disappear. That's how I implemented and documented (in choices.txt).

Kind regards,
Roel
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel De Nijs wrote:In my opinion only the lock-method should throw a RecordNotFoundException, the update, delete and unlock methods shouldn't. When a record is successfully locked, it can't magically disappear.


<agreed />
 
Matt Lobo
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The record isn't "magically" disapearing. The delete(..) method is being invoked on that record. It's actually being manually deleted. Again, ignoring underlying implementation - because yes without calling unlock your cache will still have a lock recorded for that record so the record exists in terms of the cache but it doesnt exist in terms of persistence. That's just implementation and its not necessarily what the instructions indicate.
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Again: the methods update, delete and unlock in my own custom interface (which extends the given interface) do NOT have a "throws RNFE" clause. Simply because a record which is successfully locked, can not be deleted by any other client than the one having locked that client. If the record is deleted prior to the lock, the client will get a RNFE and the record will not be locked successfully.
That's my interpretation of the assignment and my solution. And I know this simplifies the solution a lot, because you don't have to catch RNFEs which will never occur. You can have your own interpretation/solution and as long as you justify your decisions (and not violate any "must" requirement), you'll be fine and pass
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic