• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Some Locking Advice

 
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All

I am not an expert in threading but maybe one of you experts can help. My assignment involves using cookies to unlock and lock a record I have being looking through the various threads and this is what i am intending to do.

I create a synchronized hashmap which uses the record number for a key and object that contains the cookie used to lock a record and the record number.


Within my lock method I check the hashmap to see if it contains an object for a particular record number. IF it does I retrieve this object and then lock on this object using a synchronized block.

For example within the method:


In my unlock method I would then remove the object from the
hasmap and call notify all

From my understanding using a synchronized hashmap means that only one thread can carry out an atomic operation at a time on the map.

Can anyone see any problems with this approach would I need to perform some kind of synchronization when I get the object from the hashmap

Thanks

Stephen

[Andrew: put the source code between [code] and [/code] UBB tags]
[ June 15, 2004: Message edited by: Andrew Monkhouse ]
 
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think you are synchronizing on the wrong object in your lock method. You want your thread to wait as long as the hashmap contains the record you are trying to lock. You should get the object lock on the hashmap and not an object in the hashmap.

Also, I recommend using HashTable in favor of HashMap because the former has synchronized methods whereas the latter does not.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Stephen,

Welcome to JavaRanch and this forum.

I have edited your post to put the code between [code] and [/code] UBB tags. Doing this ensures that indenting is preserved, which makes the code easier to read. When you are writing your post, there are a number of buttons just below the edit pane, which will insert the tags for you, so you don't have to remember what they are.

If you would like to edit your original post so that you can see what I have done, you can click on the button that is just above your post.

It is not clear in your psuedocode what will happen if the lock object does not exist in the HashMap. It appears you will not have an object to synchronize on.

Anthony's suggestion of using a synchronized collection object (such as HashTable) might make sense in your case where you are accessing the collection outside of the synchronized block (but only in that case). But if you do decide to use it, then you may want to make an explicit comment in your code saying why you are using one of the old collections instead of one of the new collections.

Regards, Andrew
 
Stephen Patrick
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks guys

here's the updated lock method I tested it today with 10 client threads and it seemed to work fine. However the only place that I might see a problem is the second last line where a new RecordLock oject is created is it possible that a thread could prempt after its creation and another thread could take over create a new RecordLockObject place it in the hashmap then the previous thread could come back to life and overwrite the RecordLock object just inserted with the one it created before it prempted.



Thanks again
 
Anthony Watson
Ranch Hand
Posts: 327
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

is it possible that a thread could prempt after its creation and another thread could take over create a new RecordLockObject place it in the hashmap then the previous thread could come back to life and overwrite the RecordLock object just inserted with the one it created before it prempted



Yes.

Also, let's say that object = null, meaning that the record is not locked. Then before you create the new record lock, another thread creates a record lock for the same record and puts it in the HashMap. Then, your original thread is running again and it does not check again if object == null, so it just creates a new record lock and replaces the one just put there in the HashMap.
 
Stephen Patrick
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Anthony

I changed it to lock on a synchronized hashmap rather than an individual record as I need to get this finished at least this way is safer. I lock on this object in lock and unlock, don't have a need to lock on the hasmap in update,create, delete etc as it is already locked and these methods won't be called if the record is locked.

Stephen
reply
    Bookmark Topic Watch Topic
  • New Topic