Re: Shark transactions question

Hello Monique

you wrote:
> Hello Shark team,
> 
> We are evaluating Shark 1.1-2 in order to replace Shark 1.0.1 used in
>  our project and we hoped a shark transaction issue. We want to ask
> you how to solve our problem. Here is the case: We have a simplified
> process with four activities: A | v B => S1 |     | v    v S2
> 
> 
> - A is a manual activity. It creates a document; - B is a manual
> activity. It waits the user to download the document until a
> deadline. If the user downloads the document before the deadline,
> then S2 activity is started, otherwise (the deadline is reached) S1
> activity is started; - S1 is an automatic activity. It is a
> subprocess (started by deadline event of activity B) which notifies
> the user by e-mail and delivers the document. In some conditions the
> mail delivery fails and throws an exception; - S2 is an automatic
> activity. It is a subprocess that deletes the delivered document. It
> might fail and throw an exception;
> 
> The exceptions thrown are normal, expected behavior. The issue is in
>  Shark transactions handling.
> 
> Here is the scenario that troubles us: 1. Activity A generates a
> document and completes normally; 2. Activity B completes normally
> (the user downloads the document before the deadline); 3. Activity S2
> is started, but its tool agent fails - some Shark transaction is
> rolled back;
> 
> Here the behavior in question starts: 4. The process execution
> returns back to activity *B*.  This time there is no one to complete
> it. Activity B starts *again* and this time it is terminated by the 
> deadline condition; 5. Activity S1 starts (user is going to receive
> notification, despite he already downloaded the document). Activity
> S1 completes normally and proceeds to S2; 6. Activity S2 starts
> *again* and fails again. The Shark transaction is rolled back and
> process execution returns to step 4.
> 
> While S2 fails constantly, this Shark behavior loops the process 
> infinitely and makes it a good spammer.

O.K. I should remember this, might come in handy ;-)

> Now, our questions are: - Could you provide more information on Shark
> transaction life time?

In XPDL 1.0 you cannot design your transactions. We had problem how to
determine transactions in Shark, so we started with: "each method call
will be executed in one transaction" rule. Although this might have
strange side effects (as shown by Roland last winter) we think it's 
generally good one. As both yours and Roland's examples show, Shark 
will, once started to execute some process instance, greedily fetch 
every activity to execute until "manual" appears.

> - We think that each activity should run in a separate Shark 
> transaction. This will ensure that if a later activity fails, it
> would not affect the already closed (completed, terminated)
> activities.

What about sub-flow (or block) activities? Should they be executed in 
one or many transactions?

> - What should we do in order to ensure that each activity in our 
> processes will be executed in a separate transaction?

Make their finish mode - manual, but then your application takes 
responsibility to complete them.

> - What solution (process design) you will recommend in similar
> situations?

If you expect that some tool could throw exception, consider using 
exception transitions.

hope this helps
-- 
Vlada

--
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws