cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: VERY odd exceptions...
Date Wed, 26 May 2004 07:57:34 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote:
>>Spotted the problems, which are actually twofold in the TreeProcessor:
>>- sitemap modification date is checked to be before or equal 
>>to the date when the treeprocessor was built, meaning 
>>continuous rebuild if the sitemap date is in the future
>>- treeprocessor disposal (and hence its component manager) 
>>occurs as soon as change is detected, even if some other 
>>request (either in another thread or through a "cocoon:") 
>>currently use that treeprocessor, leading to the 
>>The first problem is easy to solve, but the second one is 
>>more tricky. 
>>My current thinking about it is to add a concurrent requests 
>>counter and disposal flag. When a sitemap change is detected 
>>the flag is set to true. The treeprocessor will be disposed 
>>if the disposal flag is true _and_ the concurrent requests 
>>counter is zero.
>I think we have the second problem in Cocoon since our first version :(
>I always thought about adding a counter for the concurrent requests
>in a tree processor, but always forget about it :( Regarding
>performance: is this a problem as the counter has to be synchronized?

I was just looking in the VM spec if a increment operation on an integer 
is atomic or not. My opinion it has to be in the case of class members 
as the increment is surrounded by getfield/putfield instructions.

But the overhead should be minimal, as only the increment/decrement 
operation have to be synchronized.

Sylvain, currently working on the fix.

Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message