|
|
|
|
|
|
Understanding the WebLogic Process Integrator Transaction Model
This section explains how transactions are handled in WebLogic Process Integrator applications, including the following topics:
For an overview of transactions, and details describing transaction processing and EJBs, see Programming WebLogic JTA in the WebLogic Server documentation set, available at the following URL:
http://download.oracle.com/docs/cd/E13222_01/wls/docs60/jta/index.html
How a Transaction Is Started
The following three actions trigger WebLogic Process Integrator to begin or resume its execution of a workflow, and may mark the start of a new transaction:
Whether or not an API method call also starts a new transaction depends on whether the calling application currently has a transaction context. If an external transaction context currently exists (that is, if the application has created a transaction using JTA or has inherited a JTA transaction), the WebLogic Process Integrator Enterprise JavaBean (EJB) uses it; otherwise, the EJB container automatically creates a new transaction in which to execute the call. With one exception (the Audit EJB), all EJB methods in the public API use container-managed transactions with the TX_REQUIRED transaction attribute.
Both XML and time-based events always start a new transaction.
Note: The WebLogic Process Integrator Worklist application executes user commands by calling methods on the Worklist EJB within a discrete transaction. When you work with tasks in the WebLogic Process Integrator Worklist application, the EJB container creates an encompassing transaction in which to execute each command. For example, the EJB container creates one transaction in which to execute a task, another in which to mark a task as done, a third in which to reassign a task to another user or role, and so on.
How the Transaction Is Committed
To understand how the transaction is committed, you need to understand:
Each topic is described in detail in the following sections.
How a Workflow Instance Is Processed
When first instantiating a workflow, WebLogic Process Integrator executes the Created actions for all tasks in the workflow. It then processes the Start nodes, as follows:
The progress of the transaction after the initial instantiation depends on how the template definition is defined. Activation events propagate outward along the paths emanating from the point of origin, according to the built-in processing rules for each node type.
The following table describes the processing rules for each node type.
How a Workflow Instance Reaches a Quiescent State
When processing a workflow, WebLogic Process Integrator returns control to the system when there are no more actions to execute synchronously—that is, when the workflow instance enters a quiescent state, in which it waits for the next request.
Specifically, the workflow instance enters a quiescent state when the following conditions are true:
A quiescent state also marks the end of a transaction (and results in the transaction being committed) if and only if a new transaction was started at the point that WebLogic Process Integrator was last triggered. If an external transaction context exported before the API call trigger, then the external transaction remains in effect, and control is returned to the calling application. For more information, see How a Transaction Is Started.
When an action instantiates a subworkflow, all work performed by the subworkflow up to the point where it enters a quiescent state (if ever) occurs within the same transaction as the calling workflow. This work typically includes execution of actions in all called Start nodes, activation of all successor nodes associated with each Start node, and the actions associated with each successor. This processing propagates through the subworkflow, resulting in either in completion or quiescence, according to the rules previously described. If the subworkflow runs to completion (that is, it does not quiesce), the Completed actions in the parent workflow will also be performed within the same transaction. If the Completed actions include an action to mark a task (for example, the parent) as complete, processing continues and the MarkedDone actions are performed, and successor nodes are activated.
How Exceptions Are Handled
When WebLogic Process Integrator catches or throws an exception, the decision to commit or roll back the transaction depends on the following two factors:
The active exception handler can perform associated corrective actions and identify one of the following methods with which to proceed:
If the user transaction has not already been set for rollback only and the exception is recoverable (in other words, if the exception is a workflow warning), and the exception occurred while an action was being processed or an event variable was being set, the system allows the exception handler to decide the outcome. Otherwise, the system sets the user transaction for rollback only, invokes the active exception handler, and then rethrows the exception.
If the container creates the transaction, then it commits or rolls back the transaction when control is returned to it from WebLogic Process Integrator. (Control is returned when the workflow instance reaches a quiescent state, as described in How a Workflow Instance Reaches a Quiescent State.)
If an application enlists a WebLogic Process Integrator EJB in an external transaction and this EJB throws an exception that does not result in the user transaction being set for rollback only, the transactional behavior is defined by the application. On the other hand, if the WebLogic Process Integrator call succeeds, there is no guarantee that the transaction will be committed by the external application (or by the EJB). An exception or other error condition may occur subsequently, resulting in the rollback of the entire transaction.
How to Force a New Transaction to Start
You can force a new transaction by defining a dummy task action that causes the current workflow instance to reach a quiescent state. (For information describing how a workflow instance reaches a quiescent state, see How a Workflow Instance Reaches a Quiescent State.)
For example, you can force the workflow instance to enter a quiescent state by defining one of the following task actions:
Examples of Transactions
When executing business operations within a workflow instance, the following factors impact whether the business operations are treated as a single transaction or as multiple transactions.
Specifically, whether the workflow is defined such that the existing transaction enters a quiescent state before all business operations are executed.
If you want an application-defined EJB to participate in the current WebLogic Process Integrator transaction, then the EJB must be deployed with one of the the following container-managed transactional attributes: Mandatory, Required, or Supports. For a detailed description of these settings, see Section 16.7.2 in the Enterprise JavaBeans Specification 2.0, published by Sun Microsystems, Inc.
The following sections provide examples for defining a workflow such that the business operations are defined as part of the actions of one task, and the actions of multiple tasks. In each case, an example is provided illustrating a single transaction and/or multiple transactions.
Example 1: Business Operations Defined as Actions in One Task
For the first example, suppose that you want to execute three EJBs, as separate business operations, and as part of the actions of a single task. Based on how you define the task properties, the three business operations can be treated as a single transaction or as multiple transactions.
Single Transaction
To have the specified business operations treated as a single transaction, the following example shows how you might define the task actions in the Activated Actions tab in the Task Properties dialog box.
Figure 7-1 Transaction Example: One Task, Single Transaction
In this example, all business operations are invoked upon task activation, and are treated as a single transaction. Multiple Transactions To have the specified business operations treated as multiple transactions, the following example show how you might define the task actions in the Activated and Executed Actions tabs in the Task Properties dialog box. Figure 7-2 Transaction Example: One Task, Multiple Transactions
In this example, a subset of the business operations (EJB1 and EJB2) are invoked upon task activation, as one transaction. Once the Assign task "EJB1" to user "joe" action is executed, the workflow instance enters a quiescent state, and waits for the next request. The first transaction is marked complete, and the Executed actions are performed. The EJB3 business operation is then invoked, as a separate transaction. In this example, if an exception occurs during the processing of EJB3, the active exception handler performs the associated corrective actions and identifies the method by which to proceed. The first transaction will not be impacted by an exception that occurs in the second transaction. For more information, see How Exceptions Are Handled. Example 2: Business Operations Defined as Actions in Multiple Tasks For the second example, suppose you want to invoke three EJBs as separate business operations, as actions in three separate tasks. Again, based on how you define the task properties, the three business operations can be treated as a single transaction or as multiple transactions. Single Transaction For this example, consider the following workflow template. Figure 7-3 Transaction Example: Multiple Tasks, Single Transaction
Then, the workflow instance does not enter a quiescent state before the execution of any business operation, and all three business operations are treated as a single transaction.
Multiple Transactions
This example illustrates how you might define a dummy Post XML event to force a quiescent state (and force a new transaction to start). For more information about forcing a new transaction to start, see How to Force a New Transaction to Start.
For this example, consider the following workflow template.
Figure 7-4 Transaction Example: Multiple Tasks, Multiple Transactions
Note: It is possible that the Event Watch may not have been triggered, at the time an incoming event notification is delivered, and the associated message may be missed and/or ignored. You can use addressed messaging to guarantee message delivery by defining the required message header fields and time-to-live value, as described in Guaranteeing Message Delivery.
Then, EJB1 and EJB2 are treated as a single transaction, and EJB3 is treated as a separate transaction.
In this example, if an exception occurs during the processing of EJB3, the active exception handler performs the associated corrective actions and identifies the method by which to proceed. The first transaction will not be impacted by an exception that occurs in the second transaction. For more information, see How Exceptions Are Handled.
|
|
|
|
|
|
Copyright © 2001 BEA Systems, Inc. All rights reserved.
|
