• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

lock() logic

 
Matt Pavlovich
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi guys,

A while ago there was some talk of people who had failed because if a recordNumber was already in their map, a SecurityException was being thrown, instead of the thread giving up the lock and waiting until it was notified. However, the delete and update methods state: "Throws SecurityException if the record is locked with a cookie other than lockCookie. " So obviously there must be some logic for this Exception being thrown. So here is my question: When my delete (or update) method is called, and the record is already locked with a different lock cookie, the SecurityException is thrown (from within the lock()), and then immediately after that the thread releases the lock on the object and waits. So the exception does not end the thread, it only precedes its waiting. This seems appropriate according to my interpretation of what needs to be done. For me the locking logic and the database modification logic are in two separate classes, so this was the easiest thing to for me to do. Does this sound logical? It does to me...but I'm not the one grading it. ;)

Let me just clarify that a call to delete() calls lock(), and the SecurityException, (if any) is thrown and caught from within the lock() before the thread gives up the lock and waits to be notified.

Thanks for your input.
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
You should NOT call lock/unlock from within your update/delete methods! To update a record you should make 3 seperate calls to your Data class. Your update/delete methods should do what their names intend: just update or delete the record. Otherwise your design will be considered poor (each method should have its own specific responsability, remember high cohesion). And you'll also be in trouble, because you won't be able to prevent double bookings that way.

A few scenarios and what should happen (in my opinion):

t1.lock(1);
t2.lock(1);
--> t2 should wait, no exception should be thrown

t1.lock(1);
t2.lock(2);
--> both threads should own lock on the record

t1.lock(1); // returns 100
t2.update(1, 100);
--> record should be updated

t1.lock(1); // returns 100
t2.update(1, 200);
--> SecurityException should be thrown (from update)

t1.update(1, 100);
--> SecurityException or IllegalStateException should be thrown, based on your understanding of the instructions.
 
Matt Pavlovich
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel,

Thanks for your response. I should clarify because I over simplified and I realize now reading it again my intended meaning did not come through. Lock is not called from within the method, but within the parameters. Thus, I have:



The delete() then compares the local lockCookie variable with the one it retrieves from the Map to make sure the record can be deleted using that lockCookie. That being said, is it bad practice to call methods from within parameters to get values like this?

Thanks,
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
It's not bad practice (we use it in the application we are developing/maintaining), but I didn't do it in my scjd-application. Drawbacks: less readible and harder to debug.
 
Matt Pavlovich
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Great, thank you. I agree with you about the Cohesion issue, and will for sure make certain that I don't have it all bunched up.

Have a good one...
Matt
 
Matt Pavlovich
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Further on this topic...

The lock() states:
//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.

The delete() states:
//Throws SecurityException if the record is locked with a cookie
//other than lockCookie.

Am I to understand that the word "locked" as it pertains to the lock() is referring to a Thread having the lock on (in my case) my mutex, whereas locked() as it pertains to the delete() means that the record is in the Map?

Thanks.
Matt
 
Matt Pavlovich
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
and...

It seems that if I am to do the following:


that I am going to need some kind of method that calls all three by calling it. For instance:



This is how it is done anyway, in Roberto's thread tester, except he does it in a Threaded context with a call to run() instead of my fullCycleDelete. My way would lack cohesion. But would is be acceptable (i.e considered cohesive) if it were done in my class as Roberto has it done in his Thread test? It is tough to find a cohesive solution when the three things depend on each other so heavily.

Thanks,
Matt


 
Matt Pavlovich
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never mind...I get it. I had my "House" moment. The delete and update methods are not to be called unto themselves to affect the change in the database. Such was not the intent of the developers of the exam (I believe), since we are never required to actually use these methods in the GUI. I had been trying to test data.delete(1, #), getting one call to this method to work with all three which was not happening. Now it is clear.
 
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
Matt Pavlovich wrote:I had my "House" moment.

I guess you are referring to House MD, because when I see some fragments of that series I can't follow that guy and just having the same feeling with your explanation. Totally no idea what you are trying to say.

You call lock-method to lock a record. As a result you generate a lockCookie which is added to the map of locked records (or some other data structure); or the thread/client who wants to lock the record has to wait because the record is already locked by another thread/client. In the update/delete methods you just have to verify that the record which is updated/deleted is locked with the given lockCookie. If it is, just perform the action; otherwise throw a SecurityException. And finally don't forget to unlock the record. Seems pretty straightforward.
 
Matt Pavlovich
Ranch Hand
Posts: 98
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel,

You are right, it is straight forward. My confusion stemmed from combing these methods (poor cohesion). However, it did not seem like I was violating cohesion at the time because locking/unlocking is a very real part of the delete and update methods. Thus, I did not see it as needing to do three separate things, but just one - delete or update. This was causing a lot of confusion as to how certain things are possible. But then I realized my mistake. If I look at each method's requirements, and make sure that each does what it supposed to do when called by itself, all three then fit together perfectly if called in order. My error stemmed from a preconceived point of view.

Thanks,
House, MD



 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic