• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

B&S What to do with delete

 
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 284
Netbeans IDE Firefox Browser Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Oricio Ocle
Ranch Hand
Posts: 284
Netbeans IDE Firefox Browser Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 284
Netbeans IDE Firefox Browser Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 31
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Petr Hejl
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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...
 
Petr Hejl
Ranch Hand
Posts: 68
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
What a stench! Central nervous system shutting down. Save yourself tiny ad!
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic