aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Should delete() also remove the entry from the lock map? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Should delete() also remove the entry from the lock map?" Watch "Should delete() also remove the entry from the lock map?" New topic
Author

Should delete() also remove the entry from the lock map?

Clemente Biondo
Greenhorn

Joined: Aug 31, 2010
Posts: 2
Hi,
first of all, as it's the first time I write here, I'd like to thank everyone for making this forum a great source of information.
I've some doubt regarding delete/unlock policy; basically I am unsure if the delete method should also remove the lock or not and I'm looking for some advice on this matter.
I've searched the forum and found similar topics but I think that there are aspects of the problem that needs to be discussed a little more.
I've the following primitives in my assignment:

Now consider This Scenario:


Now what's the sense of holding the record number in the lock map of a record that does not exists anymore?
Suppose that the thread t1 terminates without unlocking the record 100, that
entry in the lock map will never be deleted, so all the threads waiting to acquire a lock on record 100
will wait forever. While this scenario can happen also when updating a record, in the case of the delete
method simply there is no reason to allow this course of action.

//And another thing... suppose that another thread creates a new record before t1 unlock record 100
//The Data class may return 100 as new record number because the record is now available from the
//point of view of the flat file
int recNo= t2.create(data);
//Now the lock of the record number 100 that was created by t2 is hold by t1 (!)

Maybe I'm wrong but I've interpreted the documentation statement of the delete methos as
"delete the record an free all associated resource, lock included", and while the points
I've raised can be addressed also if t1 needs to explicitly release the lock by an unlock call
I think that the locking mechanism could me more simple and robust in the first case.
What do you think? Is my design choice acceptable or do you think I may incur into some
sort of penalization for doing so?

Thanks,
Clemente
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5273
    
  13

Your delete method should only delete the record, not remove the lock on this record. That's why you have an unlock-method.

Not unlocking the record after a delete (or update) is mistake from the developer and a bug in your program. And of course you could be penalized for "unlocking" the record in your delete method, because each method should have a specific, dedicated purpose and not do other things behind the scenes (high cohesion).


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Clemente Biondo
Greenhorn

Joined: Aug 31, 2010
Posts: 2
Hi Roel,
thanks for your answer.
I thint that coesion in this case means that every method of the interface must satisfy a single, specific, clearly defined scope.
Analyzing the lock/delete/unlock sequence from the point of view of the caller code I really don't understand what we gain by having three separate calls to delete a record, let let me clarify this.
I am the caller code, I want to gather exclusive lock on a record, so i call lock().
Then I want to delete a record, so I call delete(); it's reasonable to expect that all the resources associated with the deceased record must be freed.
At this point, why I, the caller, must perform another call? What's the scope of the third call, the record is gone. Dead. Kaput.

Anyway, I prefer to play it safe and take your advice.

Clemente.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5273
    
  13

Clemente Biondo wrote:I thint that coesion in this case means that every method of the interface must satisfy a single, specific, clearly defined scope.

Indeed And such an approach has many advantages: it will make your code simpler, less error-prone and easier to maintain. For example: another developer has a look on your code and sees a lock-call, but nu unlock-call when a record is deleted. He might wonder: why is that: maybe it a bug, because when updating a record you have lock/update/unlock sequence? Another example: when you add the free-the-deceased-record code to your delete-method (could be just a call to unlock-method itself) you add extra complexity to your delete-method and when you need to perform some extra logic you have to be careful not to break the application (maybe you work on another project and some junior has to maintain your code)

Clemente Biondo wrote:I want to gather exclusive lock on a record, so i call lock().
Then I want to delete a record, so I call delete(); it's reasonable to expect that all the resources associated with the deceased record must be freed.
At this point, why I, the caller, must perform another call? What's the scope of the third call, the record is gone. Dead. Kaput.

That's a very reasonable explanation and if you decide to follow that approach, don't forget to mention this in your choices.txt.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Should delete() also remove the entry from the lock map?