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 LockManager Implementation 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 "LockManager Implementation " Watch "LockManager Implementation " New topic
Author

LockManager Implementation

Rachna Chaturvedi
Greenhorn

Joined: May 02, 2002
Posts: 21
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
Ranch Hand

Joined: May 13, 2002
Posts: 301
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?


scwcd, scjd, scjp<br /><a href="http://natejohnson.us" target="_blank" rel="nofollow">http://natejohnson.us</a><br /><a href="http://rice.kuali.org" target="_blank" rel="nofollow">http://rice.kuali.org</a>
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
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


Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction. - Ernst F. Schumacher
Mag Hoehme
Ranch Hand

Joined: Apr 07, 2002
Posts: 194
Hi,
maybe my requirements are a little bit different: I am required to implement the methods

and

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!


Mag
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
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
Greenhorn

Joined: May 02, 2002
Posts: 21
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
Ranch Hand

Joined: Apr 07, 2002
Posts: 194
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
Ranch Hand

Joined: Jun 09, 2002
Posts: 295
hi rachna,
Tuhada E-mail Id ki hai ?. I want to mail you.
Tuhada dost,
Gurpreet
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
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
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451

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
Ranch Hand

Joined: Apr 07, 2002
Posts: 194
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
Ranch Hand

Joined: Apr 07, 2002
Posts: 194
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
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
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
Ranch Hand

Joined: May 13, 2002
Posts: 301
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
Ranch Hand

Joined: Apr 07, 2002
Posts: 194
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.
 
Consider Paul's rocket mass heater.
 
subject: LockManager Implementation