cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vadim.gritse...@verizon.net>
Subject RE: Sitemap parameters object & Threads
Date Thu, 20 Dec 2001 18:19:19 GMT
Marcus,

This parameters object you are referring is read-only by semantics, but
not by syntax. It is used as an optimization, instead of writing:

>   if (isSelected("userstatus", "permitted", listOfMaps,
>                new Parameters(), objectModel)) {

sitemap uses static instance. The solution is to have unmodifiable
wrapper parameters class available, as it is done in java collections
library. Then, sitemap could be modified to use it:

>   /** An empty <code>Parameter</code> used to pass to the sitemap
components
> */
>   private Parameters emptyParam =
>       Parameters.unmodifiableParameters(new Parameters());

Hope this is clear enough,

Regards,
Vadim

> -----Original Message-----
> From: Marcus Crafter [mailto:crafterm@fztig938.bank.dresdner.net]
> Sent: Thursday, December 20, 2001 12:42 PM
> To: Cocoon Developers Mailing List
> Subject: Sitemap parameters object & Threads
> 
> Hi All,
> 
> 	Hope all is well.
> 
> 	On avalon-dev there's been a short discussion about the
> 	Parameters object that is used in the generated sitemap
> 	class. I thought I'd bring it up here so we can flesh out a
> 	solution.
> 
>         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();
> 
> <snip>...
> 
>   if (isSelected("userstatus", "permitted", listOfMaps,
>                emptyParam, objectModel)) {
> ----------------------
> 
> 	The problem is 2 fold, and has to do with the 'emptyParam'
> 	reference when it's passed into the invocation of selectors and
> 	actions, etc:
> 
> 	1. The Parameters class itself is not thread safe. Concurrent
> 	updates to the one object may corrupt data.
> 
> 	2. There is only one parameter object across the whole sitemap,
> 	accessed by all threads, and potentially many pipelines.
> 
> 	The second point is the killer if a developer decides to set a
> 	parameter in a selector, or action, etc, and read it back
elsewhere.
> 	The problem is that the one object is shared among all threads -
if 2
> 	threads update the object (regardless of whether it's threadsafe
> 	or not), results can be undefined if they use the same key.
> 
> 	As far as I can see there's no real need to be able to set
> 	parameters in this object in selectors and actions, etc, as the
Request
> 	object can handle sharing of data between pipeline components
via
> 	set/getAttribute (or is there some other use for it ?).
> 
> 	If this is the case, we could make the parameters object
read-only
> 	before it's passed to selectors, etc, which would prevent this
problem
> 	from occuring (for example by wrapping it, or toggling its
> 	read-only flag).
> 
> 	Alternatively, we could change the generated sitemap code to
> 	create a new Parameters object per thread. I'm not sure how much
> 	this influences other uses of this object though. Perhaps
> 	someone else a bit closer to that part of the code might be able
to
> 	comment better ?
> 
> 	I'm wondering what everyone else's thoughts are on a solution
> 	for this as it seems 'emptyParam' is used almost everywhere in
> 	the generated sitemap class, and could be a touchy thing to
> 	change.
> 
> 	Any comments/thoughts ?
> 
> 	Cheers,
> 
> 	Marcus
> 
> --
>         .....
>      ,,$$$$$$$$$,      Marcus Crafter
>     ;$'      '$$$$:    Computer Systems Engineer
>     $:         $$$$:   ManageSoft GmbH
>      $       o_)$$$:   82-84 Mainzer Landstrasse
>      ;$,    _/\ &&:'   60327 Frankfurt Germany
>        '     /( &&&
>            \_&&&&'     Email : Marcus.Crafter@managesoft.com
>           &&&&.        Business Hours : +49 69 9757 200
>     &&&&&&&:
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message