aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes locking - why do we have to identify the client? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "locking - why do we have to identify the client?" Watch "locking - why do we have to identify the client?" New topic
Author

locking - why do we have to identify the client?

Jon Park
Greenhorn

Joined: Apr 20, 2008
Posts: 16
hi all,

i was checking out the old posts to get an answer for the following question, but the answer isn't too clear to me.

question : (by David Winters Junior)
|why do we need to identify the client at all duirng locking?

answer : (by Alex Belisle Turcot)
|You need to know which client has the lock, to make sure that
|only this client will be allowed to update/delete a record..
|Which is the purpose of locking the record.
|
|If you don't identify the client, then your update/delete got
|no way to check if the "caller" is the "owner" of the record:
|1. Bob locks record 2.
|2. Alice tries to update record 2.
|3. Alice is not the client owning record 2, the operation is rejected.
|4. Bob tries to update record 2.
|5. Bob is the "owner" of the record and the operation is successful.

well, since you'll always be calling methods in this order:
lock()->update()->unlock()
alice would not be trying to update the record before she locks it first(which is possible only after bob unlocks the record),
thus step2 will never take place. so i'm thinking no thread will ever try to do any operation before they lock the record first. what am i missing here?

thanks

[ April 20, 2008: Message edited by: Jon Park ]
[ April 20, 2008: Message edited by: Jon Park ]
Mary John
Ranch Hand

Joined: Sep 17, 2007
Posts: 109
Hi

this is one thing that I doubted for long.

So here is the answer.

we find it difficult to understand the need for client identification
because we assume that application should always call
lock-update-unlock, in that order This is the business logic that we provide on top of what SUN interface is supposed to do.
Ofcourse all our application calls it in this way, and should do so to prevent other clients accessing a locked record.

But in general, assume you are only asked to just implement the interface that SUN has provided. and Now if you look at update method, it says that update should be allowed by client actually owned the record. and if some other (not ours) application is using this interface, and and is calling update without actually calling lock then that is where we need to make sure that it is the client that actually owned the lock is the one that is updating it

hope you got it now.


SCJP 5.0<br />SCJD working on it
Alexander Duenisch
Greenhorn

Joined: May 29, 2006
Posts: 24
Basically, you're right.
But the interface specified in the assignment papers makes no assumptions on the method calling order. It is a general contract that has to account for the possibility of illegitimate use. Thus, it identifies clients in order to cope with "faulty" applications that do not call in the lock()->update()->unlock() order.


---------------------------<br />OCUP-F, SCJP 5.0, SCJD, SCWCD
Jon Park
Greenhorn

Joined: Apr 20, 2008
Posts: 16
thanks Mary and Alexander,
now i understand what's going on.
mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
hi;

personaly i don't call lock()->update()->unlock() sequence, but i call
lock()->read()->validate()->update()->unlock() sequence.

regards
Mohamed Darim.
John Mattman
Ranch Hand

Joined: Feb 18, 2008
Posts: 45
Hello All,
Are you all forcing a time on lock. For example are you allowing the lock on a record for a particular duration? If so how are you guys doing it?

I have a scenario like this.

Client A locks record at a particular time.

Client A runs into some exception and got killed.

Now the record is still locked and locked for ever as the server is still running.


After some time the Client A comes back alive and tries to acquire the same record, since his id is still associated with that record , he can access it.

If the client A does not return to access that locked record , that record is locked for ever. so are you guys implementing a thread that cleans up all locked records after certain time? Let me know how you guys are implementing it?

John
-------------
Scjp 5.0
[ April 21, 2008: Message edited by: John Mattman ]
mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
hi John;

from the JavaDoc for the interface provided by sun, it is not required to
free resource for the thread that don't unlock it explicity.

so for the thread that lock the record, set the unlock method in the finially block.

what you think ?

Best regards.
Mohamed Darim.
John Mattman
Ranch Hand

Joined: Feb 18, 2008
Posts: 45
From the JavaDoc for the interface provided by sun, it is not required to
free resource for the thread that don't unlock it explicity.

so for the thread that lock the record, set the unlock method in the finially block.

what you think ?


Hi Mohamed,

I am doing the server side locking. And i am also not using lock.lock mechanism. I am using a hasttable as a logical lock.I am running a thread that monitors the hash table. If a record is locked for a specific amount of time(may be more that one minute), then the thread releases the lock on that record. Is this ok?.

[ April 23, 2008: Message edited by: John Mattman ]
[ April 23, 2008: Message edited by: John Mattman ]
Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
To Jon Park:

I had difficulty understanding the use of the so-called "cookie" value returned by the lock method and used by the unlock method to release the record.

Like you I thought, I need not darn stupid cookie, I just need to know if the record is lock or not.

At the end, I used the cookie to identify the thread that locked the record and I changed a bit my implementation of the lock method to take into account the possibility that the current thread already owns the record lock. This is the only use I could find for the cookie value.

Somewhat like this:



In other words, if it is locked with the same cookie, then I do not await and let the thread proceed with the operation.

Now, this is only useful if there is a possibility to have nested record locks, which in my design is not. Because as you well mentioned, I get the lock, do the work and release it. I never get a nested lock anywhere.

To mohamed sulibi

You said you follow the following approach:


lock()->read()->validate()->update()->unlock() sequence.


I think you might like to reconsider the performance issue. The idea of a lock is to retain a resource as minimum as possible. In your approach you retain a lock while reading and validated data. This could mean a lot of time of this resource being retained. That is why the approach of lock, update, and release is so common.


To John Mattman

You said:


If a record is locked for a specific amount of time(may be more that one minute), then the thread releases the lock on that record. Is this ok?.


So, you are automatically releasing a record? I do not know if that is the best approach. I had use another approach in the past, but a bit different. If after certain amount of time, if a thread cannot obtain the lock, then it fails and throws RecordNotFoundException. Somewhat like this:



But in this case I do not release the lock in question (which is hold by another thread). What I do is that I fail to obtain the record lock.

But what you are saying is a bit more difficult to implement. It implies that I need some sort of timer that determines when a thread got the record lock and after certain amount of time, if such thread has not released the lock, then you release it automatically. Although it sounds very nice, I think I would not try such complicated idea.

The only reason I can foresee for a record lock to be hold indefinitely is if a thread that requested the lock dies before releasing it. I think this could be a corner case. Perhaps pursuing a simpler design could be a better idea. But hey, I have not finished my assignment. I am just saying what I think...

What do you think?

I hope this helps!
mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
hi;

consider the following description:

// ..., 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.
public long lock(int recNo) throws RecordNotFoundException;

from the above we see that the unlock must be explicit by the same client
lock the record. otherwise using automatic unlock for the record is over head. and it is not needed.

for my approach:
lock()->read()->validate()->update()->unlock()

i think the performace is not matter in the certification and this idea is what mentioned in all people passed the certification; also i don't expose
these operations to the client instead i pass a ref to data object to adapter object (Service) that adapt the adaptee methods to provide just two methods
consider the following snippet of code found in the Service implemenation:



what you think ?

regards.
Mohamed Darim.
John Mattman
Ranch Hand

Joined: Feb 18, 2008
Posts: 45
Hi Mohamed,
My idea was to clean up the locks that were locked by in active clients.For example.

The client A locks the record and before the atomic operation has completed, the user closed the client A gui. In that case the record is still in the locked mode. After all this thinking, i realized that since i am doing the server side locking, the lock is released by the server side code anyway. I may not need the separate thread monitor for releasing the locks. I would remove the monitor. Thanks for your input.
mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
hi;

thank you all to your notes, i will add your disicion as reason to don't expose the db interface to client.

Regards.
Mohamed darim.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: locking - why do we have to identify the client?