cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject Re: Continuation invalidation strategy
Date Tue, 10 May 2005 14:32:42 GMT
Peter Hunsberger wrote:
> On 5/10/05, Leszek Gawron <lgawron@mobilebox.pl> wrote:
> 
>>Peter Hunsberger wrote:
>>
>>>On 5/10/05, Leszek Gawron <lgawron@mobilebox.pl> wrote:
>>>
>>>
>>>>Vadim Gritsenko wrote:
>>>>
>>>>
>>>>>Leszek Gawron wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Vadim Gritsenko wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>If you want to tinker with ContinuationsManagerImpl, take a look
at:
>>>>>>> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111323704203839
>>>>>>
>>>>>>
>>>>>>Strange I missed that post ..
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Unsynchronized access to WebContinuationsHolder from
>>>>>>>invalidateContinuations() simultaneously with write access in
>>>>>>>generateContinuation() should reliably cause
>>>>>>>ConcurrentModificationException.
>>>>>>
>>>>>>
>>>>>>I do not quite get the problem. Doesn't it cause
>>>>>>ConcurrentModificationException now?
>>>>>
>>>>>
>>>>>It should - I've not seen it though.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>Other thing is how can invalidateContinuations and
>>>>>>generateContinuation be run concurrently. invalidateContinuations
is
>>>>>>invoked only for expired sessions - how can new continuation be
>>>>>>generated for that session?
>>>>>
>>>>>
>>>>>Bad example then. Here is better one:
>>>>>
>>>>> invalidateContinuations() gets Iterator on continuationsHolder.holder
>>>>>map.
>>>>> invalidateContinuations() calls _invalidate()
>>>>> _invalidate() calls disposeContinuation()
>>>>> disposeContinuation() modifies continuationsHolder.holder map.
>>>>>
>>>>>After that,
>>>>>
>>>>> invalidateContinuations() calls next() and causes
>>>>>ConcurrentModificationException.
>>>>>
>>>>>Seems to me invalidateContinuations() should have while(!empty) loop
>>>>>instead of iterator.
>>>>
>>>>Still HashMap has no interface other than iterator to get it's contents.
>>>>you can either iterate through hashMap.iterator() or
>>>>hashMap().keySet().iterator() - no difference, both are synced.
>>>>
>>>>any ideas?
>>>
>>>
>>>I've seen this problem with the 1.4.2_02 JDK, don't know if it exists
>>>elsewhere. The Sun docs claim syncrhonizing on the hashMap should
>>>solve the problem but it doesn't. The solution I came up with was to
>>>build an array instead of using an iterator, eg:
>>>
>>>                Object[] list = targetObjects.keySet().toArray();
>>>
>>>
>>>Peter Hunsberger
>>
>>I doubt it will work:
>>
>>AbstractCollection.toArray() is in fact the implementation for
>>HashMap.KeySet.toArray():
>>
>>    public Object[] toArray() {
>>       Object[] result = new Object[size()];
>>       Iterator e = iterator();
>>       for (int i=0; e.hasNext(); i++)
>>           result[i] = e.next();
>>       return result;
>>    }
>>
>>also uses iterator.
> 
> 
> Building the array and then walking it is different than using the
> iterator to walk the key set directly.  The exception comes when you
> touch an object in the key set that is accessed through the iterator. 
> With the array, you're no longer using the iterator at the time you
> touch the object.  As a result you don't get the exception (not that
> you should have gotten it in the first place).
> 
I see. I'll change the code then.

I do not know how memory intensive .toArray() in production environment 
might be. There may be a lot of continuations to clear on session 
invalidation.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Mime
View raw message