Excuse me if this has been addressed before, I am little crazy right now .
I was wondering how you guys handled the concurrency between the find & create methods.
I currently have the find method iteration over the "cache" object synchronized, which means I need to synchronize
the put on the cache in the create method. This bothers me because technically on a search, only one thread would be able to perform
that operation at a time, when no "creates" are ongoing. (Its like synchronizing the find method completely and only allowing 1 thred to access it at a time) I was wondering if that concerned anybody and how you handled it
Thanks for the response... Actually, I am working with synchronized blocks just for that reason, because synchronizing the methods
only provides so much protection. You still have to provide synchronized blocks right?
Thread 1 ---> inside synchronized method 1 iterating through object a
Thread 2 --> inside synchornized method 2 modifying object a
This scenario has the possibility of concurrentmodification exception.
If you synchronize the complete method I don't see why you would need to provide synchronization blocks. So that's not right at all! If thread1 is in synchronized methodA of objectX, then thread2 (which wants to execute synchronized methodB of objectX) simply has to wait until thread1 has finished executing methodA.
I have been synchronizing on individual objects,
lock method -- synchronizes on the room object
unlock -- synchronizes on the room
find -- synchronizes on the data cache
create -- synchronizes on the data cache
Do you think it would be better to try and synchronize the lock method on (this)? as well as all teh other methods.... My locking mechanism
is performing quite well... no deadlocks, but I am concerned that there might be something i missed.. that chance of throwing that exception or
I would advice to synchronize all methods on the same object (this) instead of every method synchronizing on another object, just for the sake of simplicity. This might be a bit less performant, but according to the instructions simplicity is preferred above performance.
Roel De Nijs wrote:I would advice to synchronize all methods on the same object (this) instead of every method synchronizing on another object, just for the sake of simplicity. This might be a bit less performant, but according to the instructions simplicity is preferred above performance.
That's what I did, with a comment in my choices document that I'd revisit it if load testing showed there was a performance problem.
I was synchronizing sometimes on multiple objects, as you said, the lockedRecords map, and the room object, the datacache, sometimes multiple in an method... but overall, I had no deadlocks, and the performance was great.... but it does leave an opening for holes... and when someone comes in to maintain
that, they might move something and not necessarily understand why I did what I did.
I switched to synchronizing on this and although it looks good from a deadlock standpoint, it is much slower... no matter..
But your right, and its somethign I should have just done from the beginning, which is make it simple.. Thank you two for the help.