lock() called twice by same client

[Martin Naskovski]

I have a dilemma as well on this topic since it is not clarified in the instructions -
if a client(thread) called e.g. lock(34) twice in a row, what should the behavior of lock() be then?
Should it let the lock be reacquired (since it is already acquired) after we check that the same client(Data object) is doing it?
Or should this behavior not be allowed (e.g. throw an exception)?

[John Smith]

if a client(thread) called e.g. lock(34) twice in a row, what should the behavior of lock() be then?

The sequence should be lock-read-modify-unlock. Your second call lock(34) should wait until the first sequence is complete and record 34 is unlocked.
Eugene.

[Martin Naskovski]

Hi Eugene - I understand what you said, but did you also mean it even if the _same_ client calls lock() on the same record twice in a row? Or should I not worry about every possible scenario lock() can be called by? Thanks .
Martin

[Barry Gaunt]

If you notice some "funnies" like this, you could make it part of the documented contract of the method that the client must not try to reaquire the lock a second time, and if he does, the behaviour of the method is unspecified.
You have shown the assessor you are aware of a problem, but have deferred it to "SCJD++".

[John Smith]

Martin Ford: Hi Eugene - I understand what you said, but did you also mean it even if the _same_ client calls lock() on the same record twice in a row?
Yes, same thing should happen, -- the second lock() should wait() until it is notified that the record was unlocked.

[Prakash Krishnamurthy]

Yes, same thing should happen, -- the second lock() should wait() until it is notified that the record was unlocked

eugene, I am little confused here. If the client has to wait for the unlock to lock it again, shouldn't the server side lockmanager be doing this? Lets say for example, there are 20 clients trying to book 1 seat on record number 34 at the same time.If I am understanding this right, from the client I let Client 2 wait till the first client has unlocked record no 34 ,then I let client 2 do the lock- modifying-unlocking then client 3 and so on and so forth.

[John Smith]

eugene, I am little confused here. If the client has to wait for the unlock to lock it again, shouldn't the server side lockmanager be doing this? Lets say for example, there are 20 clients trying to book 1 seat on record number 34 at the same time.If I am understanding this right, from the client I let Client 2 wait till the first client has unlocked record no 34 ,then I let client 2 do the lock- modifying-unlocking then client 3 and so on and so forth.

Yes, you got it right.

[Prakash Krishnamurthy]

I am doing it differently
I have many clients trying to access the same record at the same time on a remote database. I dont do anything on the client except locking-modifying-unlocking. But there could be multiple calls to lock(int) method on the server at the same time. On the server I have LockManager as a singleton class which handles all the logic for locking. It basically checks if there that record is hashed or not and then hash's it as a proof.
If I do what you have suggested; by ensuring that while a client is processing a lock-modify-unlock, all other clients wait till the first one finishes; then am I not ensuring that on the server there is only one thread at one time trying to lock the same record? Then there would be no need to handle multiple thread's on the server except if they are for different records.
This is much easier than what I have done...but can you comment on what you agree on and on what you dont.

[John Smith]

If I do what you have suggested; by ensuring that while a client is processing a lock-modify-unlock, all other clients wait till the first one finishes;

Read carefully, the question was about locking the same record. If the remote clients are trying to modify different records, no you don't have to wait.

[Prakash Krishnamurthy]

Eugene, I wasn't talking about locking different records at all.
I wrote the following

If I do what you have suggested; by ensuring that while a client is processing a lock-modify-unlock, all other clients wait till the first one finishes; then am I not ensuring that on the server there is only one thread at one time trying to lock the same record? Then there would be no need to handle multiple thread's on the server

What I meant is if Client 1, 2 and 3 are trying to lock record number 5 at the same time, and on the client if you have logic so that only one client at any time can be invoking the lock method on the server then it gets really easy because you dont have to do thread contention on the server for every record. There is no queue on the server for the same record.

In my design Client 1, 2 and 3 can invoke lock method on the server at the same time. I queue the threads on the server.
All I wanted to say was that I dont have have clientside logic to queue threads trying to book the same record, everything is done on the server.
I wanted to know if this was a good design or a bad one.
:-)

[John Smith]

Prakash,
I am totaly confused now. When I say that the client should wait, I mean the wait() call inside the LockManager. The remote client that unlocks the record issues a notify() to all waiting thread. The waiting threads wake up, check if the record was unlocked, and proceed from there.
It looks to me that your design is the same as that of most people here, we are just using different terminology.
Eugene.