aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes delete() and unlock() 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 "delete() and unlock()" Watch "delete() and unlock()" New topic
Author

delete() and unlock()

Lara McCarver
Ranch Hand

Joined: Dec 09, 2003
Posts: 118
Because of the way I am implementing things, it seems that it will be easier if I say that if you call lock() and then call delete(), the server will do an automatic unlock of the record, since the record doesn't exist anymore anyway.

I think this interpretation of the requirements is OK, but I'm not sure. The only thing I can say that would support it is, notice how the delete() method() throws an exception if the record is not found. That would imply that you aren't supposed to have to unlock() a record after you delete() it.

Does this interpretation sound OK to people?

I added the documentation for the Data class below, for convenient reference.

// Deletes a record, making the record number and associated disk
// storage available for reuse.
public void delete(int recNo) throws RecordNotFoundException;

// Locks a record so that it can only be updated or deleted by this client.
// If the specified record is already locked, the current thread gives up
// the CPU and consumes no CPU cycles until the record is unlocked.
public void lock(int recNo) throws RecordNotFoundException;

// Releases the lock on a record.
public void unlock(int recNo) throws RecordNotFoundException;
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11422
    
  85

Hi Lara
notice how the delete() method() throws an exception if the record is not found. That would imply that you aren't supposed to have to unlock() a record after you delete() it.
I would read this as stating that you are not supposed to delete a record that doesnt exist .

Your solution does look good to me.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Hi Lara,

Personally I don't like the broken symmetry of your solution (sometimes locked records must be unlocked; sometimes they don't), but I do agree that your solution is absolutely acceptable.

Frans.


SCJP 1.4, SCJD
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11422
    
  85

Hi Frans,

I think it is a reasonable design decision to automatically unlock a record after deleting it. Since the unlock method throws RecordNotFoundException another programmer using your Data class might decide not to call unlock after deleting the record, which could result in other clients waiting for a lock that will never be unlocked.

Since this is a design decision, it would have to be documented of course.

Regards, Andrew
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944
I went with the automatic unlocking of a deleted record. As the unlock() call would throw a RecordNotFoundException. If I didn't automatically unlock the record then, should the record number get reused after a create, it would have been automatically locked.

I made it clear in my choices and API that this was the case.
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Hi Andrew,

I didn't say it was an unreasonable choice; just not the one I would prefer. If I imagine the specification of the lock method, there would probably be something along the lines of:

All locked records must be unlocked with a call to unlock, unless the record is deleted.

It's those exceptions to the rule which eventually someone will forget.

Frans.

P.S. if I were to unlock a record automatically upon delete, then I would take it another step further and also automatically lock the record. Because I cannot think of a business case where I would need to have a separated lock and delete.
(This is just a rant, because implementing delete with an implicit lock probably violates the instructions).
[ July 18, 2005: Message edited by: Frans Janssen ]
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Hi Matt,

If I didn't automatically unlock the record then, should the record number get reused after a create, it would have been automatically locked.


That all depends on the total design of course. In my create method, a record was only eligible for reuse when it was deleted and unlocked. I don't think that extra condition made my solution any more complex.

Frans.
Vrinda Werdel
Ranch Hand

Joined: Jan 03, 2004
Posts: 75
Hi All,

I need some clarification on this topic. In my implementation (URLYBird), I have a DBAdapter
which calls



to achieve the locking while bookig a room. Apparently, I do not expose any delete operation in my DBAdapter. So my understanding understanding of 'delete(int recno)' was to implement it in the Data class with a synchronized block around the RandomAccessFile instance handle (physical locking).

Does this mean, that the delete() method in data class ends up calling the lock and unlock methods as below:



I am probably missing somehting in this discussion. I looked at other threads in the forum addressing this issue. But to no avail. Appreciate, if somebody can guide me thro' this.

regards

Vrinda
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Hi Vrinda,

You don't need to call lock and unlock from your delete method. Your delete method however must adhere to its contract, i.e. it must only allow to delete a record that is locked by the same client. If you don't expose your delete method that would be a hypothetical situation of course.

Frans.
Vrinda Werdel
Ranch Hand

Joined: Jan 03, 2004
Posts: 75
Frans,

This

Your delete method however must adhere to its contract, i.e. it must only allow to delete a record that is locked by the same client.


means that, one of the ways to ensure this is by having a delete interface in the DBAdapter. However, when the examiner does the testing, he would test only the 'delete()' interface from the Data class. So, in order to adhere to the contract, I would be required to call lock()/unlock methods inside my delete() method. (which is not a great idea, as I am of the opinion that all the methods in the Data class perform specific low level db tasks. so we dont necesarily put in too much orchestration logic in there as the same happens in the DBAdapter class (per my design).) Is there a better way to handle the contract that I am missing?

regards

Vrinda
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11422
    
  85

Hi Frans
I cannot think of a business case where I would need to have a separated lock and delete.
But how would you allow an application to delete a record only if it has not yet been booked? I can't see how to do this without allowing a separate lock and delete (unless you put business logic right down in your Data class, which I think is not a good idea).

Regards, Andrew
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
Hi Frans But how would you allow an application to delete a record only if it has not yet been booked? I can't see how to do this without allowing a separate lock and delete (unless you put business logic right down in your Data class, which I think is not a good idea).

Hi Andrew.

I stand corrected. That is indeed a very realistic business scenario where a separate lock for delete would come in handy!

Frans.
Frans Janssen
Ranch Hand

Joined: Dec 29, 2004
Posts: 357
So, in order to adhere to the contract, I would be required to call lock()/unlock methods inside my delete() method. (which is not a great idea, as I am of the opinion that all the methods in the Data class perform specific low level db tasks.


Hi Vrinda,

I don't think that the contract requires (or even suggests) you to call lock from within delete. It only asks that the delete method shall check that the record has been locked before.

This does not require you to add delete to your adapter class, but it does require that your delete methods somehow shall know which records have been lcoked by what clients.

Frans.
Vrinda Werdel
Ranch Hand

Joined: Jan 03, 2004
Posts: 75
Thanks for the clarification Frans.

regards

Vrinda
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: delete() and unlock()