Delete and RecordNotFoundException

[Bill Robertson]

2 Qustions that have been bothering me since day one:
1. For delete how do you handle unlock. In a sense you can't. But lets
say you log on and delete record 4, then immediatly create a new record
that ends up in the 4th space - so its now the fourth record. But in your
Collection that you store your locked objects, record 4 is going to be in
there as locked - which makes no sense! - it was just created.
2. Very similar to number 1, how do you handle
RecordNotFoundException thrown from lets say book. You can either not call
unlock which then you run into problem number 1, or your unlock ends up
throwing it also so you loose the actual trace and integrity of where the
exception first occured.
I split up my unlock so that the actual unlocking of the record takes
place in another method that unlock calls. Its only parameter is record
number. Would just calling this method and not the entire unlock method be
a valid solution?
[ January 01, 2004: Message edited by: Bill Robertson ]

[Ken Krebs]

Bill,
Question #1:
In my case, unlock only looks in the locked map, not the contractors collection, so it only throws RecordNotFoundException if it's not in the locked map. Why should unlock care if the record is not in the contractors collection since unlock's only purpose is to remove the corresponding lock from the locked map if it's there ?
Question #2:
In my case, if the lock method looks in the contractor collection and can't find it, the exception will be thrown and update will never be called. Once it finds it during lock, it should not fail during the update invocation because the lock prevents any other thread from deleting it. My book method contains the calls to lock/update/unlock and throws RecordNotFoundEception up to its client if it occurs and the client will report it to the user.

[Bill Robertson]

Hey Ken,

In my case, unlock only looks in the locked map, not the contractors collection, so it only throws RecordNotFoundException if it's not in the locked map.

makes sense and clears things up for me - thanks

In my case, if the lock method looks in the contractor collection and can't find it, the exception will be thrown and update will never be called. Once it finds it during lock, it should not fail during the update invocation because the lock prevents any other thread from deleting it. My book method contains the calls to lock/update/unlock and throws RecordNotFoundEception up to its client if it occurs and the client will report it to the user.

I see, so your contract for update also applys to book - am I correct?
This is a very nice solution. My only minor issue is calliing RecordNotFoundException for two different conditions. Unlock if not in
locked collection, for lock if not in contractor collection. But its the nicest solution I have seen yet.
thanks Ken,
bill

[Ken Krebs]

Bill,

I see, so your contract for update also applys to book - am I correct?

Wrapping update and delete in lock/unlock calls is a contract specified in the DBMain interface by the assignment. Doing this within a single method call is a separate contract I specified in my Javadoc.

This is a very nice solution. My only minor issue is calliing RecordNotFoundException for two different conditions. Unlock if not in
locked collection, for lock if not in contractor collection. But its the nicest solution I have seen yet.

I really don't see why you consider this an issue as the context of an occurence of a RecordNotFoundException being thrown is simply not the same for unlock as it is for lock.