This is the method defined in the DBAccess interface:
So what happens if the cookie passed in does not match the cookie of the locked record? Shouldn't this method also throw RecordLockedException? Right now I just do nothing if that's the case. What do you think?
I have version aejb and the signature of the unlock method is like yours. I guess you are right, a RecordLockedException should be thrown in the case the record is locked but the cookie does not match...I'm not sure whether I am going to change the interface or do something else... I'll keep you posted... And shouldn't the update (and delete) method throw RecordNotLockedException if an update is attempted without first locking it? Or should we automatically lock the record if the latter is unlocked when invoking update (or delete) and then automatically unlock it when the update (or delete) method has been performed? [ September 06, 2002: Message edited by: Valentin Crettaz ]
This is my interface. Notice it's called DBAccess.
My interface requires a matching lock cookie to write or unlock the record. Looks like your interface has more freedom in terms of how the access control is implemented. I also have to create the exceptions in the suncertify.data package. I just did what it says and import the exceptions I need.
SCJP2
I can't take it! You are too smart for me! Here is the tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss