cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: GroupBasedProfileManager
Date Thu, 05 Jan 2006 08:59:31 GMT
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, 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 Ziegeler - Open Source Group, S&N AG

View raw message