[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xalan-dev
Subject:    Re: Thread safety, Extension Elements & state.
From:       John Gentilin <gentijo () eyecatching ! com>
Date:       2004-04-26 19:10:24
Message-ID: 408D5EA0.8080500 () eyecatching ! com
[Download RAW message or body]

Joe,

See below...
-JG

> You should also be concerned about the possiblity of out-of-order
> evaluation, unless your extension code is completely taking over evaluation
> of that subtree. Xalan doesn't _currently_ reorder stylesheets, as far as I

Do you mean reorder templates ?

I plan to use the same mechanism that the redirect Extension Element uses to
execute child templates. So I am assuming that if I have the following XSL

<xsl:template match="/">
  <myExt:email>
     <xsl:apply-templates select="to" />
     <xsl:apply-templates select="from" />
     <xsl:apply-templates select="body" />
  </myExt:email>
</xsl:template>
  
<xsl:template match="to">
  <myExt:to>
     <xsl:value-of select="." />
  </myExt:to>
</xsl:template match="to">

Templates from & body are the same.

The <myExt:Email> will be evaluated first and since the extension element <myExt:Email>
calls executeChildTemplates, the to/from/body will all be evaluated after and as children
of myExt:email. 

With that said, I am also assuming that the order that the to/from/body templates may be
evaluated as a function of executeChildTemplates may be different if Xalan was to
reorder templates.

> extension to extension. That also avoids any multitasking issues since each
> executing stylesheet has its own variable stack. I grant that it's a bit
> ugly, though.

It seems that an extension element can only get a parameter and not set one. 
So I could create a parameter as a global, or as a local as long as it is passed 
along with all the apply-templates, then fetch that parameter from the current 
extension element as some kind of mutex between extension element calls. Just
thinking out loud here.

This leads into my original question about instance control of Extension Elements.
Is there a separate method cache on a per stylesheet, per thread instance. i.e.
The same template instance that produces two transformers on two threads, will 
it create two separate instances of a declared extension element. If this is true, 
then don't need the stylesheet parameter and I can maintain control using class 
variables.

This differs greatly from Extensions because an extension instance becomes a parameter
and you can have many separate instances, per Transformer, not just stylesheet / template.

> If you're willing to risk reordering... I *think* the SQL Extension has
> dealt with the threadsafety issue, but I don't remember how offhand. Might
> be worth checking that code.

I did not code anything specifically into the SQL extension to handle thread safety.
I think because each query/pquery becomes its own variable in a Transformer, thread
safety within Stylesheets is not an issue. 


> 
> ______________________________________
> Joe Kesselman, IBM Next-Generation Web Technologies: XML, XSL and more.
> "The world changed profoundly and unpredictably the day Tim Berners Lee
> got bitten by a radioactive spider." -- Rafe Culpin, in r.m.filk
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xalan-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xalan-dev-help@xml.apache.org


-- 
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546

    Contact Info
gentijo@eyecatching.com
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917


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

[prev in list] [next in list] [prev in thread] [next in thread]