aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Hashtable's put method problem in locking 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 "Hashtable Watch "Hashtable New topic
Author

Hashtable's put method problem in locking

Gurpreet Saini
Ranch Hand

Joined: Jun 09, 2002
Posts: 295
Hi konovo and morris Ltd Co.
In my lock method, I faced a problem with put()method. As you know it takes two params. Object key, Object value. The value is ok for the reason that I am using it with record to lock. But problem comes with Object value. If I use "this", then it will simply point to the current object and in that case my current object at that time is RemoteDataAccess. Please suggest me which is the better feasible way out ?, such that it may point to clients object. On the other hand I do not want to modify the signature of lock method.
Thank you,
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
If you are using a ConnectionFactory (to hand out unique RemoteData objects to each client) then the RemoteData is the "client" that you want to use as the value.
Maybe I am missing something...


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>
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Also I'd suggest using a HashSet or HashMap instead of the older HashTable.
I used HashSet, but I didn't need to include the ConnectionObject as a client ID. But that is because I didn't use a LockManager. A LockManager is the better way to handle locks.
Mark


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Gurpreet Saini
Ranch Hand

Joined: Jun 09, 2002
Posts: 295
Hi mark,
Can you give me little broader spectrum of LockManager ?. Is it possible to use clientID when we use LockManager ?. If possible then give me some inkling over it.
Thank you,
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
Yeah it is possible and one of the main reasons to use a LockManager (for the client id)... just use the Google button and search for LockManager, all one word, and you will find detailed explanations about the subject.
Gurpreet Saini
Ranch Hand

Joined: Jun 09, 2002
Posts: 295
Hi reader,
I am using Hashset as suggested. But tell me is there any need for taking clientID. As far as specf go they ask for record locking and unlocking on records. Not on the record based on clientID. No where in the spec they had mentioned use clientId or client object. Any way, I tested my lock / unlock with 21 threads / clients. Functioning like butter but at 22 thread it says ConnecteException. But the problem which worries me is whenever I print my Hashset which keeps tracks of locked records. Always shows me 0. On, the other side application moves smoothly. I fancy that the thread may be that fast that it writes and unlocks so fast that it merely gives any time to other thread.
Thank you,
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
Originally posted by Gurpreet Saini:
But tell me is there any need for taking clientID. As far as specf go they ask for record locking and unlocking on records. Not on the record based on clientID. No where in the spec they had mentioned use clientId or client object.

Here is the quote from my specs that I took as needing a client id ...

The unlock method simply removes the lock from the specified record. If an attempt is made to unlock a record that has not been locked by this connection, then no action is be taken.

... so it looks to me that you better not unlock a record if it is held by another client. If you have a way to ensure this without a client id then you are probably fine... I just thought the id was an easy approach.
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

In my submission I did not use client ID for locking. Just because each Connection object that each user gets also had it's own HashSet to keep track of what it has locked, so that it can't call unlock unless it is in the clients own HashSet.
With the LockManager you pass the record number and the Connection Object to lock method, and when you call unlock, it looks for the record in the HashMap and sees if the Connection Object associated with it is the same as that which is calling unlock.
In LockManager you need to use the Map because it holds and Object as the key, and an Object as the value. It is a Key-Value type match. HashSet just holds an Object with no Key.
Hope that helps clear things up.
Mark
rachel meyer
Greenhorn

Joined: Aug 22, 2002
Posts: 6
Mark,
Is your LockManager a singleton?
rachel meyer
Greenhorn

Joined: Aug 22, 2002
Posts: 6
Also, does the LocalDataObject have an empty lock and unLock method, while the RemoteDataObject calls the LockManager's lock and unLock methods?
Do you have to override the 'equals' and the 'hashcode' methods in the RemoteDataObject for comparing it in unLock method?
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
Originally posted by r dal:
Also, does the LocalDataObject have an empty lock and unLock method, while the RemoteDataObject calls the LockManager's lock and unLock methods?

yes and yes... about the singleton, I have seen it go both ways (for the lock manager), but I think that pattern is overused and used wrong an aweful lot, so I did not use it for my lock manager.
rachel meyer
Greenhorn

Joined: Aug 22, 2002
Posts: 6
Thanks Nate. Did you override the equals and the hashcode method in your RemoteDataObject? if not, how did you compare the objects in the unLock method?
Nate Johnson
Ranch Hand

Joined: May 13, 2002
Posts: 301
Originally posted by r dal:
Did you override the equals and the hashcode method in your RemoteDataObject? if not, how did you compare the objects in the unLock method?

no... i wanted it to be the exact same object so i just used client.equals(lockingClient), so if it does not equal itself, then dont unlock... i probably could have used client == lockingClient in my case
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

R Dal, I did not use the LockManager solution, that is why I didn't need "clientID" for unlocking.
Mark
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

"R Dal"-
Welcome to the JavaRanch! Please adjust your displayed name to meet the
JavaRanch Naming Policy.
You can change it
here.
Thanks! and welcome to the JavaRanch!
Mark
Gurpreet Saini
Ranch Hand

Joined: Jun 09, 2002
Posts: 295
Hi reader,
Yes, it is something which each and every individual takes this bite of puzzle in its own way. And I understood what Nate had quoted in this post. From Lock to unlock it is one journey of a client and hence I presume that it is "this connection". So, "this connection" refers to the journey made by client from lock to unlock. Now, if the record was never locked by this connection then it is obviously to say that unlocking on that record is of no value. In other words program should not choke or hang at this junture. To broader this puzzle more I have an inkling that you test via not calling lock and explicitly call your unlock method with ofcourse on record. And Unlock must exit gracefully . So, it is in this unlock that programmer has to explicitly mention that record which was never locked should be bypassed.
And furthermore, I don't feel that if client is modifying the record. Then at a same it cannot modify other record at that very time. If it does so then what is harm ?. The concern is of record number and not the client object. And if there is no harm then what is the role of clientID or client object ?. As, far as my design goes I defend it by this justification. Please do correct me if I am wrong in my approach.
Thanks,
Michael Morris
Ranch Hand

Joined: Jan 30, 2002
Posts: 3451
Hi Gurpreet,
I'm not real sure what you're trying to say here. But my take on why it is necessary for the unlock method to ignore an unlock request on a record not currently held by the calling client is the following scenario:
  • Client A calls lock on record 1 and is given the lock
  • Client B calls lock on record 1 and must wait for the record to be unlocked
  • Client C calls unlock on record 1
  • Client B comes out of the wait pool and is given the lock to record 1 which is still held by Client A
  • Clients A and B now read the record before either has modified
  • Clients A and B now each modify the db decrementing the approprate number of seats
  • Since there were not enough seats to cover both bookings, now the db is in an inconsistent state, and we're going to have some very unhappy customers at the airport.


  • So, even though, the above is an unlikely scenario, why take chances?
    Michael 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
    Gurpreet Saini
    Ranch Hand

    Joined: Jun 09, 2002
    Posts: 295
    Hi Morris,
    What on earth makes client C to call unlock method ?. Why had you made this virtual mirage ?. Where as I think if the client is doing.
    1. lock
    2. modify
    3. unlock
    Then why client C will call unlock ?.
    Thank you,
    Nate Johnson
    Ranch Hand

    Joined: May 13, 2002
    Posts: 301
    I think that is his point... you dont know how new client or maintained client code might call the data methods... you need to watch out and plan for these cases, because they could be extremely hard to debug in the future.
    Gurpreet Saini
    Ranch Hand

    Joined: Jun 09, 2002
    Posts: 295
    Hi Nate,
    Mmmmmmm, there is weight in your words. I shall again reconsider my lock / unlock code.
    Thank you,
    Gurpreet Saini
    Ranch Hand

    Joined: Jun 09, 2002
    Posts: 295
    Hello reader,
    I doubt that lock / unlock are to be called from client side ?. Or they to be handled from server side. My RemoteDataAccess class is handling lock & unlock which resides in server pack. My question is that client has to explicitly call the lock and unlock methods or it is to be handled by the server side only ?.
    Thank you,
    :roll:
    George Lawniczak
    Greenhorn

    Joined: Aug 12, 2002
    Posts: 27
    My question is, what is the best way to test the locking mechanism, seeing as how the time between locking and unlocking a record is pretty short?
    The only way I can think of is to comment out the "unlock" logic and simply have one client keep the lock, then exit out of that client to see if the unreferenced logic works.
    How can I simulate many users by using only one computer?
    Nate Johnson
    Ranch Hand

    Joined: May 13, 2002
    Posts: 301
    Originally posted by Gurpreet Saini:
    My question is that client has to explicitly call the lock and unlock methods or it is to be handled by the server side only ?.

    Well, I think this is a personal design question and it can go either way. Just realize that the methods for locking are public, so you need to make sure someone else down the road does not screw up the database because they did not call lock and unlock in the order that you may require right now. Make your design and your code foolproof so it doesnt cause headaches down the road
    Nate Johnson
    Ranch Hand

    Joined: May 13, 2002
    Posts: 301
    Originally posted by George Lawniczak:

    The only way I can think of is to comment out the "unlock" logic and simply have one client keep the lock, then exit out of that client to see if the unreferenced logic works.

    That is the way I tested my unreferenced stuff
    Originally posted by George Lawniczak:

    How can I simulate many users by using only one computer?

    I made my code sleep in places between the lock and unlock calls. Then I could see that other clients were waiting to get the locks on records that were locked, but were not waiting to get locks on records that were not locked.... btw - I would just start multiple clients and work them myself through the GUI.
    Michael Morris
    Ranch Hand

    Joined: Jan 30, 2002
    Posts: 3451

    Originally posted by Nate Johnson:
    I think that is his point... you dont know how new client or maintained client code might call the data methods... you need to watch out and plan for these cases, because they could be extremely hard to debug in the future.

    Give the man a good Habana! It's scarey how you read my mind Nate.
    Michael Morris
    Nate Johnson
    Ranch Hand

    Joined: May 13, 2002
    Posts: 301
    Originally posted by Michael Morris:

    Give the man a good Habana! It's scarey how you read my mind Nate.

    Gurpreet Saini
    Ranch Hand

    Joined: Jun 09, 2002
    Posts: 295
    Hi Nate ,
    I thank you, for your opinion. You had made me to think again. You see I have very dull brain. The moment I start thinking I get sleep down in my eyes. Now, it will take another couple of days to rectify lock / unlock.
    Thank you,
    Michael Morris
    Ranch Hand

    Joined: Jan 30, 2002
    Posts: 3451
    Hi Gurpreet,

    ... You see I have very dull brain. The moment I start thinking I get sleep down in my eyes.

    No one who asks quesions like you have been has a dull brain. No one here thinks the less of anyone on this forum for asking legitimate, intelligent questions. Quite the contrary, true intelligence is in understanding that you know nothing. We only have a short time to acquire knowledge and the only way to accomplish that acquisition is by asking those who already have the knowledge to share it with us. So remember, we are all equals here, each bringing his own set of acquired knowledge.
    Michael Morris
    rachel meyer
    Greenhorn

    Joined: Aug 22, 2002
    Posts: 6
    Nate,
    You used the LockManager for locking and unLocking records when the database is accessed remotely.
    Is the LockManager a member of your RemoteData class? If yes, does the LockManager extend UnicastRemoteObject or Serializable?
    Nate Johnson
    Ranch Hand

    Joined: May 13, 2002
    Posts: 301
    No... my LockManager is really just a utility. It has a static HashMap of locks and has static methods, that synchronize on that HashMap, to do locking, unlocking, and cleaning dead client locks.
    PS: Even if it were a member of RemoteData, it would not have to be Serializable nor extend Uni... I have a member of Data (unchanged from the Sun download) as a member of RemoteData and it works great
    [ August 25, 2002: Message edited by: Nate Johnson ]
    rachel meyer
    Greenhorn

    Joined: Aug 22, 2002
    Posts: 6
    How did you clean up dead threads?
    How do we know when a process is terminated with a ^c that the thread is not active any more so that we can remove all the records that this thread has locked in the hashtable?
    Nate Johnson
    Ranch Hand

    Joined: May 13, 2002
    Posts: 301
    Originally posted by rachel meyer:
    How did you clean up dead threads?
    How do we know when a process is terminated with a ^c that the thread is not active any more so that we can remove all the records that this thread has locked in the hashtable?

    Well, I used the Unreferenced interface for my RemoteData object... then when it gets called it calls the LockManager.clean(id) where id is the RemoteData from the unreferenced method... then the LockManager just sits in a loop, removing all locks that have that id.
    Make sense?
    rachel meyer
    Greenhorn

    Joined: Aug 22, 2002
    Posts: 6
    Thanks.
     
    It is sorta covered in the JavaRanch Style Guide.
     
    subject: Hashtable's put method problem in locking
     
    Similar Threads
    Clarification on Synchronization.. say that three times fast
    About lock cookie generation
    Waiting Thread
    Passed SCJD
    RecordNotFoundException in locking