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
[Andrew: put the source code between [code] and [/code] UBB tags] [ June 15, 2004: Message edited by: Andrew Monkhouse ]
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.
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.
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.
posted 16 years ago
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
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.
posted 16 years ago
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.