Thanks for examining the code for me Upayavira. I saw another post in the archives explaining why it'd be too hard for the map:parts to be constructed in parallel and for no real gain (SAX events from each part coming in at random times and getting mixed up).


So I'm not sure. But please take a look at my specific problem and see if there's something I'm missing (must be!):

This is in the sitemap:

<map:match pattern="getCart">
<map:generate src="xml/getCartInfo.xsp" type="serverpages"/>
<map:serialize type="xml"/>
</map:match>

<map:match pattern="getLineItemCosts">
 <map:act type="calculate-line-item-costs"/>
 <map:generate src="xml/getLineItemCosts.xsp" type="serverpages"/>
 <map:serialize type="xml"/>
</map:match>

<!-- ***MAIN MATCHER*** -->
<map:match pattern="showCartPage">
<map:aggregate element="cart-page">
  <map:part src="cocoon:/getCart" strip-root="true"/>
  <map:part src="cocoon:/getLineItemCosts"/>
</map:aggregate>
<map:serialize type="xml"/>
</map:match>

The first map:part (whose src="cocoon:/getCart") comes out fine, and within its XSP code it pulls the shopping cart from the session. The cart just has 1 item (product) in it, and that the XSP modifies the quantity of the item from 1 to 0 (I tested that it does).

The 2nd map:part is then executed, and executes an action that calculates the subtotal for the cart by pulling the cart from the session. HERE is the strange behavior, because the quantity for the single cart item is now 1, when it should be 0 (I verified this by logging).

So now the 2nd part execution finishes by generating from xml/getLineItemCosts.xsp. I actually tried pulling the cart from the session again in this code and seeing what the quantity is....and it's ZERO!

So my question is: If my Action executes in between the 2 XSPs and both of those output 0 for the quantity, how can the Action always see it as 1? This is what got me asking if map:parts are constructed in parallel.

I'd appreciate all of your insights,

Sonny

From: "Upayavira" <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [resent] map:part's processed in parallel?
Date: Sun, 10 Aug 2003 23:56:27 +0100

Sonny,

I've taken a look at the source for the Aggregator. In that code there's no reference to
threading, however it does use a parser to interpret the sources that the <map:part>
nodes refer to. It is possible that those parsers are multi-threaded, and right now
finding that out is beyond my level of ability. Maybe someone else can help more...


Regards, Upayavira

On 10 Aug 2003 at 15:02, Sonny Sukumar wrote:

>
> [I didn't get any response, so I was wondering if somebody knows about
> this.
>   It would be really helpful.]
>
> Hey all,
>
> Are map:parts in a map:aggregate executed in parallel or in serial?
> Because I wrote one where the 2nd part should only start to be
> generated after the first has completed, but the output indicates a
> parallel execution instead of a serial one.  For example:
>
> <map:aggregate element="new-root">
>   <map:part src="cocoon:/src1"/>
>   <map:part src="cocoon:/src2"/>
> </map:aggregate>
>
> Here I need cocoon:/src2 to only begin its generation after
> cocoon:/src1 is completed.  If they do go in parallel, is there any
> way to force the parts to be generated serially?
>
> Thanks,
>
> Sonny
>
> _________________________________________________________________ MSN
> 8 helps eliminate e-mail viruses. Get 2 months FREE*.
> http://join.msn.com/?page=features/virus
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> additional commands, e-mail: [EMAIL PROTECTED]
>



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


_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* http://join.msn.com/?page=features/junkmail



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



Reply via email to