cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: GroupBasedProfileManager
Date Thu, 05 Jan 2006 14:37:31 GMT
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
>
>  
>

Mime
View raw message