Re: Shark transactions question

Hello Vladimir,

Thank you very much for your answer. You propose to set our automatic 
activities to manual finish mode, and you say: "...but then your 
application takes responsibility to complete them.". Once our automatic 
activities invoke tool agents to do something, should we understand your 
comment that the *tool agent* has to close the activity which invoked 
it? Please confirm, this is what you meant and if so, please provide an 
example how a tool agent can complete the activity that invoked it. It 
would be good if your example does not refer the Scheduler Tool Agent, 
because we find it not appropriate when Shark runs within a J2EE EJB 
container, where using threads must be avoided (our case). We could not 
find detailed information on Shark behavior when using automatic 
activities with manual finish mode. We will be very grateful for your 
help in this matter.

Another thing, we would like to have your comments on, is the usage of 
custom exceptions in exception transitions.

In our example the activity B (mail sending) can throw several different 
custom exceptions. All of them are "checked" in Java sense (not 
"run-time" ones). We looked at Shark examples. They demonstrate only 
throwing of java.lang.RuntimeException and catching as 
org.mozilla.javascript.JavaScriptException.
We find that using exception transition only on 
org.mozilla.javascript.JavaScriptException (as it is demonstrated in the 
examples) is not suitable for our purposes.

Please comment how we should define exception transitions for exactly 
our custom exceptions.

We also met issues with the deadlines recalculation:
(To be honest, it was in Shark version 1.0.1 - we still did not managed 
to test it with version 1.1-2.)
Our document creation activity might take from several seconds to a 
couple of hours. We have a timer thread that calls deadline 
recalculation relatively often (let say once a minute). Sometimes there 
are process instances, which are locked at a deadlines recalculation. 
Each such a lock causes the deadlines recalculation to stop (by throwing 
an exception) and the deadlines for the rest of the process instances 
not to be recalculated. Thus, one long running activity prevents 
execution (state recalculation) of a bunch of other processes for long 
time. This is a real issue in our Shark workflow application, because 
this prevents executing of long running processes in parallel, which is 
the main strength of the workflow technology.

Let's suppose we have three process instances all with automatic 
activities ready for execution. How many Shark transactions will Shark 
use within a single deadlines recalculation call (for these processes)? 
We expect that each process instance will be executed within its own 
Shark transaction. Please comment what happens with the transaction(s) 
and the status of the processes when an exception is thrown within the 
deadlines recalculation call.

Best Regards,
Monique

Vladimir Puskas wrote:

> 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

--
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