File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S double locking Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S double locking" Watch "B&S double locking" New topic
Author

B&S double locking

Dalibor Novak
Greenhorn

Joined: Apr 06, 2009
Posts: 6
Hello fellow ranchers,

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.

Fola Fadairo
Ranch Hand

Joined: Feb 16, 2004
Posts: 35
I simply return the existing lock cookie when the client owning the lock on the record tries to lock the same record again.
Dalibor Novak
Greenhorn

Joined: Apr 06, 2009
Posts: 6
Great! That is exactly what I would do if I knew that it is the same client trying to lock the same record again. I could do this by using RMI Factory so I could identify clients but in that case what's the point of the lock cookie? I might as well lock records using the client identifier.

K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 1966
    
    7

Honestly the assignment expects multiple clients or is a multi-threaded app. So if client A successfully locks record 1 and client B tries to lock record 1, client B should wait until client A release record 1 - at this time B will able to lock record 1.

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.


K. Tsang JavaRanch SCJP5 SCJD/OCM-JD OCPJP7
Dalibor Novak
Greenhorn

Joined: Apr 06, 2009
Posts: 6
Maybe my english isn't clear enough but I am talking about situation where someone writes a client that should work with my server. And then he writes (for whatever reason) code that tries to lock the same record twice.

Example
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.
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 1966
    
    7

Then if the same client tries to lock the same record, I think you should throw RNFE because that record is "already" locked and can't lock again.
Dalibor Novak
Greenhorn

Joined: Apr 06, 2009
Posts: 6
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.
K. Tsang
Bartender

Joined: Sep 13, 2007
Posts: 1966
    
    7

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.
Dalibor Novak
Greenhorn

Joined: Apr 06, 2009
Posts: 6
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?
mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
dears;


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.

Best Regards.
Mohamed Sulibi
SCJP, SCJD in progress (From 1/8/2007 till now but may be after 5 weeks)
Fola Fadairo
Ranch Hand

Joined: Feb 16, 2004
Posts: 35
If a client is aware of the records it is presently locking, it should not be a problem preventing it from trying to lock a record it has already locked.
Dalibor Novak
Greenhorn

Joined: Apr 06, 2009
Posts: 6
I am perfectly aware of that. However since B&S (Sun) mentions in the spec that a bunch of junior developers will be working on the code later it might be good to at least describe this potential deadlock in javadoc. Otherwise there is no warning of a potentially severe issue which may surface later.
Dmytro Stasyuk
Greenhorn

Joined: Apr 02, 2009
Posts: 5
If you don't expose your lock and unlock methods to the client application than perhaps you could implement these methods similar to the way ReentrantLock is implemented in Java, such that if the current thread already holds a lock than repeated calls to lock would return immediately.
mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
dear;

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 ?

Best Regards.
Mohamed Sulibi
SCJP, SCJD in progress (From 1/8/2007 till now but may be after 5 weeks and may be not)

 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: B&S double locking
 
Similar Threads
lock(-1)
lock method without lock cookie?
RecordNotFoundException in locking
URLyBird question
Multiple lock requests on the same record number