Marcus Crafter wrote:

> Hi Berin,
> 
> On Tue, Dec 18, 2001 at 11:20:18AM -0500, Berin Loritsch wrote:
> 
>>In what way are the same set of parameters used by different threads in 
>>Cocoon?
>>
>>We never addressed ThreadSafety as one of the Contracts for either 
>>Parameters
>>or Configuration.
>>
> 
>       Have a look at this snippet from a generated sitemap:
> 
> ----------------------
> public class sitemap_xmap extends AbstractSitemap {
>   static final String LOCATION = "org.apache.cocoon.www.sitemap_xmap";
> 
>   static {
>     dateCreated = 1007984808622L;
>   }
> 
>   /** An empty <code>Parameter</code> used to pass to the sitemap components */
>   private Parameters emptyParam = new Parameters();
> 
>   /** HashMap relating labels to view names */
>   private HashMap view_label_map = new HashMap(1);
> 
> <snip>...
> 
>   if (isSelected("userstatus", "permitted", listOfMaps,
>                emptyParam, objectModel)) {
> ----------------------
> 
>       The 'emptyParam' is passed into several cocoon components. If a
>       developer sets a parameter in a selector for example, then 2
>       threads can overwrite each other with different results (the current
>       problem we have here).


Is emptyParam supposed to be a read-only object, or something that is started
at the beginning of a pipeline?


> 
>       In Cocoon I think the problem is more fundamental in that the
>       parameters object is actually an instance level reference in the
>       sitemap object (I'm not sure if that was intended ? ie. to share
>       parameters between pipelines), but I think even a thread safe
>       parameters object would not fix thread safety there - there
>       needs to be a local Parameters object per thread passing through
>       the sitemap, or a read-only Parameters object if the developer
>       shouldn't be doing this at all.


Yep, this can only be fixed with ThreadLocal parameters objects.


> 
>       If the Parameters object remains thread unsafe, perhaps it should be
>       documented in it's class level javadocs like the Collection
>       classes so it's obvious to the developer (I'll submit a patch if
>       you like ?).


Sounds good.




-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to