All operations that will force quiescence in a workflow

Question

I have the following list of operations that will force quiescence ...
1) Timed Event actions
2) Set Due Date actions
3) Assign Task... actions
4) Send XML to Client actions
5) Event nodes
6) Done nodes
Is there anything that I am missing?
Also if someone can shed some light on the significance of the "Post
External XML Event" viz-a-viz quiescence and transaction boundries. I am
specifically interested in finding out if what happend when the transaction
mode for the "Post External XML Event" is set to "send immediately"... Will
this cause a transaction to end for the sake?
Regards,
Raoon Kundi

Answer 1

Raoon Kundi,
You can specify whether you want the message to be sent immediately, or when the
current transaction containing the Post XML Event action commits. Sending the
message immediately sends the message whether or not the transaction completes.
Sending the message on commit ensures that the message is sent only if the transaction
completes successfully and a commit is issued. If the transaction is unsuccessful
and is rolled back, the message is not sent. The default is when the transaction
commits. For more information on workflow transaction boundaries, see Understanding
the BPM Transaction Model in Programming BPM Client Applications.
Advantage of Post Immediate(immediate)
 Performance improvements in one-way asynchronous requests where an event
may be fired before transaction commits.
Caveats with Post Immediate
 Duplicate Messages: Messages may be redelivered, if request side workflow
transaction was rolled-back and retried.
 Wrong Address in Addressed Response Message: A request is originated
from uncommitted workflow running in a live transactional context, and the transaction
is later rolled-back. In this case, workflow instance will be removed, as it was
never committed, and a response for such request will not find the addressed instance
to be notified.
 No-Instance-Found-Race-Condition: A request is originated from uncommitted
workflow running in a live transactional context, and response comes back before
transaction is committed. In this case, response can’t find uncommitted workflow
instance, and retries for a configurable of times after sleeping for configured
retry interval between all retries. This will reduce the window for race condition
significantly. Improper tuning may still show the problem more often. Tuning can
guarantee robustness only when retry times*retry interval is more than transaction
timeout.
Advantages of Post Commit(when transaction commits)
 No-Instance-Found-Race-Condition is a remote possibility. Cause for all
occurrences of this race condition in “Post Commit” are outside scope of WLI (ORACLE,
for example, sometimes has shown delays between transaction commit, and row being
visible to other transactions).
 No Duplicate Messages
 Wrong Address not possible.
Caveats with Post Commit
 May add a new resource to already running transaction (slowing down 2phase
commit processing).
 Delay in posting the XML event message (only sent when transaction commits).
Which Pattern warrants which delivery mode?
 One-Way Asynchronous (fire and forget)
Ideal for Post-Immediate, but must deal with redelivery issues.
 Two-way asynchronous
Ideal for Post-Commit, for the reasons mentioned above (Post-Immediate may see
“No-instance-found race condition”, “Message redelivery” or “wrong address in
response” problems).
 Two-way synchronous
Ideal for Post-Commit, for the reasons mentioned above (Post-Immediate may see
“No-instance-found race condition”, “Message redelivery” or “wrong address in
response” problems).
Hope
"Raoon Kundi" <[email protected]> wrote:
I have the following list of operations that will force quiescence ...
1) Timed Event actions
2) Set Due Date actions
3) Assign Task... actions
4) Send XML to Client actions
5) Event nodes
6) Done nodes
Is there anything that I am missing?
Also if someone can shed some light on the significance of the "Post
External XML Event" viz-a-viz quiescence and transaction boundries.
I am
specifically interested in finding out if what happend when the transaction
mode for the "Post External XML Event" is set to "send immediately"...
Will
this cause a transaction to end for the sake?
Regards,
Raoon Kundi