I am working on a B&S assignment and I started to wonder how I should handle lock method that gets called twice by same client trying to lock same record.
Since the method signature is:
Invoking something like this in client code will lead to deadlock as server can't tell whether the lock was invoked by the same client.
Trust me I have no intention on writing such code but it could lead to trouble if someone t B&S later tries to.
I decided to use RMI in my implementation. Do you think I should go for RMI Factory solution just so I can prevent this from happening or can I just write in javadoc that lock method should not be called twice for the same record. In latter case I can also write in decisions document that this was done in order to make code simpler for junior developers.
I see your lock method returns a long. Since I didn't do B&S and my lock method didn't return a long, I think this long value is the cookie representing the client or some ID for the client. If this is true, then the returned value should be unique.
Remember the entire write process (lock -> update/delete -> unlock) should be sychronized.
client A locks record 1 and receives lock cookie
client A locks record 1 again but cannot obtain the lock as it is still held by the same client
Now if server knew that this is the same client trying to obtain a lock that it already has - no problem client get same cookie again.
My point is: if I need server that knows clients identity then I could use it to lock records and wouldn't need the locking cookie. In this case locking cookie de-facto exists only so I can honor the interface and is in fact completely redundant.
I hope I made my concern a bit more clear.
Dalibor Novak wrote:I am 100% positive that you shouldn't do this. RecordNotFoundException should be thrown if someone tries to lock record that either doesn't exist or is marked as deleted. Hence it's name RecordNotFoundException and not RecordLockedException.
Correct. You are right about that. Well it depends on how you implement your lock methods. In my case if the same client does call lock(1) twice, that thread will deadlock waiting for itself. Of course we shouldn't expect that.
So to put this thing in a short sentence. You suggest that I can allow deadlocks if same client tries to lock the same record more than once.
If I'll do that I'll definitely mention it in javadoc.
Does anyone else have opinion on this?
yes i did that as the javadoc state "the current thread gives up the CPU and consumes no CPU cycles until the record
is unlocked" ====> mean "until the record is unlocked explicitly" so in your code:
yes this situation will make deadlock in my code and i solve this problem simply by don't exposing the lock/unlock methods so i can solve the deadlock
also clients dying in the middle of his locking.
SCJP, SCJD in progress (From 1/8/2007 till now but may be after 5 weeks)
if the current thread already holds a lock than repeated calls to lock would return immediately.
i think regarding: "... if the specified record is already locked by a different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked." you mean that : "... if the specified record is already locked by the SAME client, the current thread DON'T gives up the CPU and STILL consumes CPU cycles." . i think it will break the logical record lock. ...... may be or may be not ... what you think ?
SCJP, SCJD in progress (From 1/8/2007 till now but may be after 5 weeks and may be not)