• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

B&S double locking

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

 
Bartender
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Dalibor Novak
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 3648
16
Android Mac OS X Firefox Browser Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 169
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 169
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)

 
reply
    Bookmark Topic Watch Topic
  • New Topic