Download PDF (1.3 MB) - IBM Redbooks

Avoiding two-way synchronous invocation of an asynchronous target
If the target component must be started asynchronously and its interface is of two-way
request/response style, then the target cannot be safely started through synchronous SCA
calls. After the caller sends the request to the target, it waits for response from the target.
Upon receiving the request, the asynchronous target starts a new transaction. Upon
processing the request, the target returns the response asynchronously to the caller through
the response queue. If a system failure occurs after the caller successfully sends the request
but before receiving the response, the caller transaction is rolled back and tried again. As a
result, the target is started a second time.
Taking advantage of transactional attributes for activities in
long-running processes
Although SCA qualifiers control component-level transactional behavior, additional
transactional considerations in long-running business processes can cause activities to run in
multiple transactions. You can change the scope of those transactions and the number of
transactions using the transactional behavior settings on Java Snippet, Human Task, and
start activities. For a detailed description of these settings, see “Transactional behavior of
business processes” in the Business Process Manager 8.0 information center:
http://pic.dhe.ibm.com/infocenter/dmndhelp/v8r0mx/index.jsp?topic=%2Fcom.ibm.wbpm.
bpc.doc%2Ftopics%2Fcprocess_transaction_macro.html
You have four setting choices for transactional behavior:
► Commit before
Use the Commit before setting in parallel activities that start new branches to ensure
parallelism. As noted in the information center, you must consider other constraints.
► Commit after
Use Commit after for inline human tasks to increase responsiveness to human users.
When a human user issues a task completion, the thread/transaction handling that action,
is used to resume navigation of the human task activity in the process flow. The user’s task
completion action does not complete until the process engine commits the transaction.
Starting with WebSphere Process Server 6.2.0, Receive and Pick activities in BPEL flow
are allowed to define their own transactional behavior property values. If not set, the
default value of initiating a Receive or Pick activity is Commit after. Consider using
Participates where possible because that behavior performs better.
► Participates
If the Participates setting is used, the commit is delayed and forces a longer response
time for the user. Only the Participates setting does not require a new transaction
boundary. The other three settings require the process flow container to start a new
transaction before executing the activity, after executing the activity, or both.
In general, the Participates attribute provides the best throughput and should be used
where possible. This suggestion is true for both synchronous and asynchronous activities.
In the two-way asynchronous case, it is important to understand that the calling
transaction always commits after sending the request. The Participates setting refers to
the transaction started by the process engine for the response. When set, this setting
allows the next activity to continue on the same transaction.
In special cases, transaction settings other than Participates might be preferable. Review
the Business Process Manager 8.0 information center for more guidance about this issue.
► Requires own
The Requires own setting requires that a new transaction be started.
Chapter 3. Development best practices 39