This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Release or not the lock inside the delete method? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Release or not the lock inside the delete method?" Watch "Release or not the lock inside the delete method?" New topic
Author

Release or not the lock inside the delete method?

Marcelo Camargo
Ranch Hand

Joined: Jul 05, 2007
Posts: 43
I am not sure about what to do here.
In the sequence lock->operation->unlock, if I delete a record, should I remove the lock?

We already discuss this issue before, I know, but I see we have two sides: one that defends the automatic unlock, and other that not.

I know there are motivation for both and I agree with both sides, that's my conflict...

option a) For example, a big argument for the automatic delete:
- Does not make sense to delete a record that does not exist.

option b) And a big one for the other case:
- You break the sequence lock->unlock->operation if you unlock the record inside the delete method, and the client should have to know to wich operation he need to call unlock... for some he needs, and for others not.

I first implemented using the option a, and changed to option b, but, at some time, I have a problem in the client side code: if I call delete method, and it return an exception, should I call unlock or not? In this case, I don't really know if the delete already unlocked the record before the exception... and again, I am thinking about option a...

I am in a conflict. Do someone have a very good argument for one side?

Thanks,
Marcelo.


SCJP5(93%), SCJD(in progress...), SCEA(not started yet...)
Gabriel Vargas
Ranch Hand

Joined: May 16, 2007
Posts: 145
Hi Marcelo,

I think there is no a reason to decide what is the best option, it depends on the way you implement your code. I choice a) because it is more consistent with the code i wrote, option b is also good (note secuence is lock->operation->unlock for me ). I also think it depends if you implement 2-tier o 3-tier architecture , i explain, for my 3-tier architecture is "easy" make changes over the server because i don't expose logical lock methods i expose another high level methods, but over a 2-tier architecture could be good maintain lock secuence because lock methods are exposed and somebody implement a client needs know there is a secuence than always work fine.

I hope it helps you.


Gabriel Vargas
SCJP, SCJD, now studying for SCWCD and working to be a better person
Marcelo Camargo
Ranch Hand

Joined: Jul 05, 2007
Posts: 43
Hi Gabriel,

I chose a) option too, but note that I have a 3-tier architecture too.

Even in a 3-tier architecture, where the client are not aware about the existance of the logical locking, I am writting a test code that test the DBAccess interface directlly, because I think SUN will test with this interface with an automated tool. That's because SUN sent to me the DBAccess interface, and they know how to test it. But they can't test the business interface on an automated way (they need to construct another tool to do that).

So, I am looking for all details in my DBAccess implementation, even the client will never know about it.

And, suppose another client is written, and this new client access the DBAccess interface directly... So, we need to worry about all of the details concerning the DBAcess implmentation.

That is what I am doing...

Thanks,
Marcelo.
Marcelo Camargo
Ranch Hand

Joined: Jul 05, 2007
Posts: 43
Hi Gabriel,

OK, in your business tier, that calls your DBAccess implementation, in the business delete method, what do you do if the DBAccess delete method fail? you unlock or not the record? because you don't know if the record was unlocked or not (the DBAcess method fail)...

Marcelo.
Gabriel Vargas
Ranch Hand

Joined: May 16, 2007
Posts: 145
Originally posted by Marcelo Camargo:
Hi Gabriel,

OK, in your business tier, that calls your DBAccess implementation, in the business delete method, what do you do if the DBAccess delete method fail? you unlock or not the record? because you don't know if the record was unlocked or not (the DBAcess method fail)...

Marcelo.


Hi Marcelo,

Good point. Not neccesary a call to delete method results in a deleted record , so if i want support this i think i have two options, one is change my deleted method to verify after a call to delete to my database manager class if the record was deleted (i think deleted method become ugly) and another is change deleted method to not unlock records and modify unlock method to permit unlock records than has been deleted (it would improve my method contract and class contract). I read in another threads people passed creating a contract lock->operation->unlock but i didn't underestand how do this, but after thinking and reading specifications again i find:


Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file.


Should is not a must (i see that in another thread). After thinking about that i find finally how do this contract, i copy Lock mechanism of new concurrence package (put unlock method in a finally block) and document than my unlock method don't check existence of a record to unlock it. I test this night and i hope get good results (i must change my documentation again ). Thanks for this tip.
Marcelo Camargo
Ranch Hand

Joined: Jul 05, 2007
Posts: 43
Gabriel,

I think the solution is do an unconditional unlock inside the DBAccess delete method. And, if the delete was not done, the client need to get the lock again before try again. I think if it is documented, no problem. That's what you did, right?

Are you from Brazil?

Thanks,
Marcelo.
Gabriel Vargas
Ranch Hand

Joined: May 16, 2007
Posts: 145
Hi Marcelo,

This is i done, but i didn't have an scenario when an exception is thrown and record is not deleted and my reasons to unlock this record are broken .I now think don't unlock automatically a record when is deleted is a better option for me. When method lock of Data class is called the following idiom should be used to prevent record locked is never unlocked:



So when is need to call a lock, later in a finally block must be called is always called unlock. It looks like idiom used in Lock class of the new concurrence packages. This is that i test at my home today. Any comments?

Note: I'm from Bogot´┐Ż, Colombia.
Gabriel Vargas
Ranch Hand

Joined: May 16, 2007
Posts: 145
I test these changes and it works fine, it simplyfies rules about synchronization in my code, Thanks Marcelo, there would be a problem if you not post this thread.
Marcelo Camargo
Ranch Hand

Joined: Jul 05, 2007
Posts: 43
Yes Gabriel,

I am doing the same as you !

I just finished my business and data layers. Now, I am working on the documentation and after that I will start working in network. How about you?

Marcelo.
Gabriel Vargas
Ranch Hand

Joined: May 16, 2007
Posts: 145
Hi Marcelo,

I'm working in GUI and documentation in this moment, i finished my network layer after i finish my data class and i'm reading threads when i can to improve my code and my documentation.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Release or not the lock inside the delete method?
 
Similar Threads
Locking strategy with singleton
Almost ready to hand up: Just cleaning up and have a few questions
Do I have to call lock method from within the delete method?
About:My URLyBird1.3.2 Locking
Locking strategy