My locking model

[Georgiana Lungu]

Hi,

I have few things I would like to confirm with you that are ok:

1)My specification for update and delete mentions: "Throws SecurityException if the record is locked with a cookie other than lockCookie". So I decided to let update and delete perform the operations if the record is not locked at all, without locking it, despite the horror scenario when two such operations would perform concurently, or even the scenario in which after a not synchronize update peration, checks if the record is not loc and after that another synchronyzed operation is interfering and locking it, they would still both perform the operation. I have mentioned it in choices.txt and in Javadoc of the methods. I am not sure about this... Should I also throw Security Exception if a record is not locked at all?

2)I used sockets implementation and in my DbRequest i did:

[edit]do not post complete chunks of actual code

for lock releasing whne client disconnects, is that OK?

3) I also keep a lockCookie field in the DbClient and i do this:

[edit]do not post complete chunks of actual code

If this RuntimeException is thrown, the GUI is not doing anything but the record to be locked in second place is simply not being updated, as i considered that a client trying to lock two records record at a time is just an error in implementation of the programmer that calls lock method, as I mentioned in the Javadoc and also in choices.txt. Still I am not sure if this behavior is fine.

[edit]do not post complete chunks of actual code

I didn't synchronized them as for the purpose of my application, is not needed.
I did this to prevent deadlock cause because of such a situation. Is it OK?

4) I wanted the lock()/unlock() methods to only be called by the client. because delete method from sun did not specify it also releases the lock on some record. But that lock still needs to be released after a deletation, as other threads might have already be blocked while pending for it. So I made unlock not verify if the record exists if it was locked and the lock cookie is valid, looks like this:

[edit]do not post complete chunks of actual code

I would really need some opinion about all these , thank you.

[Roel De Nijs]

1/ in my opinion a record which is not locked, can simply not be updated/deleted. First a record has to be locked, before any update/delete call can happen. When someone tries to update/delete a record without locking (or trying to lock the record 1st) I consider it as an illegal operation, so I throw an IllegalStateException

2/ what do you mean with client disconnecting? when the client exits the application? Or when a client crashes during the booking process? I think you should try to keep the cycle for a locked record as short as possible. So you could lock the record and then ask the client to enter customer id, but that could result in very long record locks. Instead you could lock the record after the client has entered the customer id.

3/ Preventing deadlock is always a good idea And I did that too: when a client tries to lock a 2nd record (or the same record twice) he will get an IllegalStateException, because that is clearly a developer mistake.

4/ After a delete you must certainly unlock the record, because like you already mentioned: other threads can be waiting for this record. Only my lock-method could throw the RNFE, the other methods (delete, update and unlock) won't, because if you have successfully locked a record, the record will not disappear, so no need to throw the RNFE from these methods.

[Georgiana Lungu]

Thank you for answer .

Regarding 1) Y, i guess you are right, I was just afraid not to fail to do anything from the specifications and i started immagining different scenarios .
Regarding 2) Y, i lock it after client has entered the id and he pressed commit button. So i guess you are right and it is no point in concerning about releasing the lock in my situation indeed, as this time should be pretty short.

Regarding 4), I know there is no need but SUN's provided interface shows the methods do have to throw this exception , but I will just take your advice then and unlock a deleted record in the delete method, after deletation is performed.

And one more thing, for cookie generation I have not used any fancy algorythm, I am only incrementing a long declared static, for each new locking registration, should i polish on that or is it fine?

[Roel De Nijs]

You should not include unlock-method in your delete method! For update/delete you'll need 3 seperate calls each time.

Most people use for the lockCookie generation System.nanoTime(), but using a static counter is also fine (just don't forget to make sure that this process happens thread-safe).

[Georgiana Lungu]

Y, I thought I should not include it as well, but my unlock needs to throw RecordNotFoundException, I need to unlock a record after I delete it, either I do not throw RecordNotFoundException for any deleted record, which does not seem ok for me as deleted records are actually like they never were, this is just a particular case, either is the solution I posted above, throwing it, only if the record was not previously locked with the passed cookie(throwing it as a particular case of SecurityException, I can not think of any other... Any advise would be welcome, thank you.

[Roel De Nijs]

To delete record 1 you should do something like:

long cookie = data.lock(1);
data.delete(1, cookie);
data.unlock(1, cookie);

So 3 seperate calls, you don't include a call to unlock in your delete-method implementation. You can throw a RNFE from the unlock-method if you want, but I didn't do it (because it makes no sense). In the lock-method a RNFE will be thrown when the record does not exist, after a successful lock a record will not disappear. When a record was locked with a wrong cookie, you can throw a SecurityException (in every method where you need to check the validity of the lockCookie). When a record is not locked at all, you can either throw a SecurityException or you can throw an IllegalStateException (I would prefer the last one and I used that one myself, although I didn't had a SecurityException in my assignment).

Kind regards,
Roel

[Georgiana Lungu]

Y Roel, I see your point, and I entirely agree and throwing that exception on unolck doesn't make any sense for me either. But the Sun specification looks like this:

public void unlock(int recNo, long cookie) 
throws RecordNotFoundException, SecurityException; 

[Roel De Nijs]

That's true Georgiana, but it does not mean the unlock method MUST throw the RNFE, it just means that it could throw one.

In my solution, I created my own interface which extends the given Sun (Oracle) interface and has a few extra methods. In this interface I overrode the delete/update/unlock methods and I removed the "throws RNFE" clause

[Georgiana Lungu]

OK, thank you, then I will remove it as well, the interface can throw it but the implementing class doesn't have to

[Roel De Nijs]

Georgiana Lungu wrote:then I will remove it as well

I would not edit the given interface (and don't forget to document your decision).

[Roberto Perillo]

Roel De Nijs wrote:I would not edit the given interface

Me neither! It is pretty likely that this would lead to automatic failure!

[Georgiana Lungu]

No, I just removed it from the implementing class, Data directly, they don't mention it needs to throw all the exceptions DB's methods throws. I hope is a decent approach.

[Roel De Nijs]

That's ok!