aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S What to do with delete Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S What to do with delete" Watch "B&S What to do with delete" New topic
Author

B&S What to do with delete

Petr Hejl
Ranch Hand

Joined: Feb 26, 2006
Posts: 68
Hi,
in my assignemnt delete should make db space and recno reusable. Before delete lock has to be obtained. This (IMHO) implies that delete method should perform unlock too. Otherwise when sb. other create record it could be yet locked.

Thanks for advise.
P.
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Hi Petr,
My lock method throws an RecordNotFoundException when you try to lock a deleted method. This implicates that cannot be owned the lock of a deleted record and therefore my delete method must unlock the record before return.
Regards


SCJP, OCMJD, OCMJEA
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Otherwise when sb. other create record it could be yet locked

Why? does your create method call lock()?
in my case, the problems will came after that...
Petr Hejl
Ranch Hand

Joined: Feb 26, 2006
Posts: 68
Just to be sure. I'm trying to solve this scenario.

A: cookieA = lock(3)
A: delete(3, cookieA) //after this record should be reusable
B: create() //here if unlocked by delete B could obtain recNo
B: lock(3) //if unlocked by delete wait although the record was created by B and since then nobody locks him

However if delete method unlocks the record, than following scenarion would be forbidden:
A: cookieA = lock(3)
A: delete(3, cookieA)
A: unlock(3, cookieA) //exception here (security or not found)

I have LockManager class for locking
Oricio Ocle
Ranch Hand

Joined: Nov 30, 2004
Posts: 284

Hello again Petr,
I can't see where the problem is:
However if delete method unlocks the record, than following scenarion would be forbidden:
A: cookieA = lock(3)
A: delete(3, cookieA)
A: unlock(3, cookieA) //exception here (security or not found)

My unlock method does not throw a RecordNotFoundException, so it simply do nothing when the specified record does not exist.
Anyway, if it throws this exception, nothing would be wrong in that scenario, since you would be trying to unlock a deleted record...

B: create() //here if unlocked by delete B could obtain recNo

Be aware how you are preventing logical data corruption, think about two concurrent record creations.
Regards
Petr Hejl
Ranch Hand

Joined: Feb 26, 2006
Posts: 68
Ok, thanks a lot.
I just want to clarify that it is reasonable to unlock record on delete.

This is the layer of logical access and locking. Other synchronization is made for file access itself - on this layer it is handled concurrect record cration.

Thanks again
S.
Xiao Di
Ranch Hand

Joined: Dec 23, 2005
Posts: 31
In my opinion, the deleted records only exist in the implementation classes and they are invisible to any database clients. Should your design base on this concept.


SCJP, SCJD, SCEA
Petr Hejl
Ranch Hand

Joined: Feb 26, 2006
Posts: 68
No doubt. What I'm asking for is: Should be unlock of record done as a part of delete method (that one from interface - delete(int recNo, long cookie) )? If no there is a trouble with lock on deleted record. If yes you can't use lock() , action(), unlock() for this case.

P.
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
For the sake of having all database methods work in identical fashion, no.
That would also give trouble if you're trying to delete a record held by another lock.

The way I've implemented it will make sure that a record can't be deleted unless the client ordering the delete holds a valid lock, and that the unlock method doesn't fail when unlocking a deleted record (though that operation would not strictly be required as there's nothing that can be done with it anyway).

My lock mechanism is independent of the actual data store, maintaining a Map of record IDs and related cookie values.
It's therefore not in any way influenced by what happens to the actual records themselves. One could disappear for all the LockManager knows and it wouldn't care less.

When locking a record, the request is forwarded to the LockManager, which waits if needed for the record to become available.
Then the lock is placed and the cookie returned.

The database operations that need locks check with the LockManager to check whether the supplied cookie is valid for the record that's to be modified.

So all operations are:
- lock
- modify (so update and delete operations, I use optimistic locking so no lock on read).
- unlock

The Data class itself doesn't actually do anything to the database either, it just relegates legal calls to the actual database file.

Might be more involved than strictly required, but I decided to make the whole database system open to change.
With the implementation of 3 classes (the metadata, database file handler, and server launcher) you can have it serve a different database format.
And I'm seriously considering making the launcher so that it will determine what actual format to initialise from the configuration file and initiate the necessary class for it using reflection...


42
Petr Hejl
Ranch Hand

Joined: Feb 26, 2006
Posts: 68
Yes, your solution is very similar to mine. But if the delete method of file handling class (delegate) makes record reusable, than create method of the same class can reuse it. This can cause that lock of newly created record can be owned by another client - this is very strange behaviour. That is what I'm discussing here.

A: cookieA = lock(3)
A: delete(3, cookieA) //after this record should be reusable
B: int newRec = create() //probably file handle class inside this method reuse deleted rec. 3, so B obtains 3
B: lock(newRec) //b can't lock 3 although it is newly created from its point of view
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
hmm, had overlooked that scenario.
But then the create method doesn't itself lock the record it creates.

While a lock on a deleted record could be held for a prolonged period, that would IMO indicate a programming error on the client side.
Documenting clearly that deletion should be followed by releasing the lock should thus be enough.

With the LockManager waiting for locks to be removed, and having a mechanism for cleaning up stale locks at intervals, that error would not lead to surprising situations (the client attempting to lock a just-created record on which a stale lock is being held by another process which has forgotten to release it would just experience an unusually slow lock method).

To enable deletion of stale locks I've implemented a Timer inside my LockManager, and used timestamps (using the new nanoTime function) for my cookies.
 
Don't get me started about those stupid light bulbs.
 
subject: B&S What to do with delete