LockManager Implementation

[Rachna Chaturvedi]

Hello all,
I have implemented my Lock Manager in the following way and am confused after reading a few posts here on the same topic.
My Lock Manager does not use a client id to lock records. The RemoteConnection Object is a singleton and each client gets a refrence of the same object.
The Lock Manager holds a HAshMap of LockedRecords and has a static method that creates the Record Object and returns it back to to the client. The Records Object has a boolean flag to indicate the status of Lock or unlock for each Record.
The whole sequence of lock/unlock is managed in the following way:
Client A - lock(27)
LockManager.getRecords(27)
Record.lock()
Client B - lock(27)
// waits

Client A - //do all modifications
records.unlock()
Client B - //do all moidifications
record.unlock();

I have no where used or felt the need to use a client Id.??
Can someone help me in identifying where the fault is in my code and how/why/when clientid is needed.
I have looked at so many post on this topic and it only adds to my confusion.
Thanks for the help in advance
Rachna

[Nate Johnson]

Well, if you can do something like this and not mess up the data, then you are probably ok...
1) a.lock(1)
2) a.modify(1)
3) b.unlock(1) -- will this be ignored?
...
If the unlock is ignored like above, then you probably don't need to worry about it. That is the main reason I have a client id... to make sure the same client that locked a row is the only client that can unlock the row.
You can not depend on the code being in the right order of locking... some other system might try to use your code in the future and really screw it up
Doe that help?

[Michael Morris]

Ditto what Nate said. There is a requirement in the instructions to ignore unlock requests by any client other than the current owner of the lock.
Michal Morris

[Mag Hoehme]

Hi,
maybe my requirements are a little bit different: I am required to implement the methods

public void lock (int recno)  

and

public void unlock (int recno)  

There is no space for any client ID ---
Although I personally would prefer to have some client ID, I think I should adhere to the requirements and restrict myself to simple locking without client IDs.
I would be grateful for any comment!

[Nate Johnson]

Originally posted by Mag Hoehme:
There is no space for any client ID ---

Do a search for LockManager in this forum... the client id is the reason for a LockManager. It allows for an id and not changing the signatures of lock and unlock in the Data class

[Rachna Chaturvedi]

HI, i want to thankyou all for making me understand that the client id is needed because the requirements
BUt i am yet to understand how this is to be implemented.
This is a very helpful site,I would like to suggest something for improving the efficiency of this site :
Can there be someway to divide up the posts in Developer Certification into categories like "Lock/Unlock", "Search Criteria", "Exception HAndling", etc. This can also prevent the repetition of questions over and over , i.e Lock Manager .

[Mag Hoehme]

Hi Nate,
I remember having read in this forum to use the current thread as client ID.
This would allow me to set the Client ID within the LockManager - no need for method signatures such as public void lock (Object client, int recno).
This idea has just come to me, and I hope it's a good idea. Any comment is welcome!
Thank you very much for your help!!!

[Gurpreet Saini]

hi rachna,
Tuhada E-mail Id ki hai ?. I want to mail you.
Tuhada dost,
Gurpreet

[Nate Johnson]

Originally posted by Mag Hoehme:

I remember having read in this forum to use the current thread as client ID.

That would be good but RMI specifically says that it does not guarentee that the same thread will be used for each request, so the same client may use 100 different thread for 100 different calls to your server... now if you are using sockets, I can not really say if the same applies.
Hope that helps some.

[Michael Morris]

Originally posted by Nate Johnson:
... now if you are using sockets, I can not really say if the same applies.

Since you would be controlling thread creation using sockets, you could use the thread as an ID if you weren't using thread pooling.
Michael Morris

[Mag Hoehme]

Hi,
Thank you, Nate, for the remark on RMI and its thread reuse.
I've pondered the problem of the client ID. If RMI does not guarantee that the same thread is used (as the spec says), a workaround could be to give the current thread a name before calling lock or unlock and using this as a client id.
Anyway, I rather think that the client ID is not really required. It is a beautiful idea, but my requirements do not mention anything indicating that this safeguard is required.
After all, the locking mechanism is a simple precaution against corrupting data, and as such the record number alone should do the job.
Any comments are welcome!
[ August 28, 2002: Message edited by: Mag Hoehme ]

[Mag Hoehme]

Originally posted by Mag Hoehme:
Hi,
Thank you, Nate, for the remark on RMI and its thread reuse.
I've pondered the problem of the client ID. If RMI does not guarantee that the same thread is used (as the spec says), a workaround could be to give the current thread a name before calling lock or unlock and using this as a client id.
Anyway, I rather think that the client ID is not really required. It is a beautiful idea, but my requirements do not mention anything indicating that this safeguard is required.
After all, the locking mechanism is a simple precaution against corrupting data, and as such the record number alone should do the job.
I also feel that locking and unlocking should be restricted to take place within the server only.
Any comments are welcome!

[Michael Morris]

Hi Mag,
If you are using a ConnectionFactory on the server and each client has a unique connection object, then just use "this" for the client ID.
Michael Morris

[Nate Johnson]

Originally posted by Mag Hoehme:

Anyway, I rather think that the client ID is not really required. It is a beautiful idea, but my requirements do not mention anything indicating that this safeguard is required.

Just be sure that if client A locks a row and then client B unlocks that row before client A does, that the unlock will be ignored... otherwise, you might get bad data. I am pretty sure that is in the specs and a client id makes the unlock check really easy.

[Mag Hoehme]

Originally posted by Nate Johnson:

I am pretty sure that is in the specs and a client id makes the unlock check really easy.

Thank you, Nate!
Now I also found it in my requirements. I was about to miss it.