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 ]
I have Version bfkq and here is the interface I got.
What I found weird in the following text is
The exceptions used in this interface must all be created as member classes of the suncertify.data package
suncertify.data, yet the interface is suncertify.db. Is there something wrong here? Mark [ September 06, 2002: Message edited by: Mark Spritzler ]
Tybon Wu
Ranch Hand
Joined: Jun 18, 2002
Posts: 84
posted
0
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.
I agree. Here's the link: http://ej-technologies/jprofiler - if it wasn't for jprofiler, we would need to
run our stuff on 16 servers instead of 3.