Yes, you are correct. Too late at night. I missed the
synchronized(this) in the methods. Out of curiosity (not that it makes
any difference), why aren't the methods just synchronized?
Carsten Ziegeler wrote:
Carsten Ziegeler schrieb:
Ralph Goers wrote:
After looking at the AuthenticationProfileManager code I decided to
review the GroupBasedProfileManager. While I'm happy to see the
read/write lock stuff gone it seems that getGlobalBaseDatas and
getGlobalDatas could have a race condition if two threads run at the
same time. Both threads could very well create the CopletBaseData or
worse getGlobalBaseDatas might clear copletDatas.object right after the
other thread has set it in getGlobalDatas.
Argh, you're right - now, the methods are synchronized...but obviously
that doesn't help. I must have written this code directly after some
party I guess. I'll have a look at it today.
Ok, perhaps the code isn't that bad...now, both methods
(getGlobalBaseDatas and getGlobalDatas) are synchronized, so only one
thread can enter them and therefore only one thread can change the
corresponding objects. At the end of the method, the map is returned and
this return value is then used for the current user profile.
So, if now another thread is entering the getGlobalBaseDatas method and
overwriting the copletBaseDatas.objects value, the first user is not
affected as he is working on his copy. At least this is how I think it
should work. WDYT?
Carsten
