Components in EAServer have a transaction type property that indicates how a component participates in transactions. You can view and change a component’s Transaction Type property using the Management Console. For PowerBuilder components, you can specify the attribute in the PowerBuilder wizards (doing so ensures that it is saved with the PowerBuilder project and not overwritten by redeployment). Allowable values are described in “Transaction type values”.
Table 2-1 lists design scenarios and the transaction type values that apply to each.
Design scenario |
Applicable transaction type values |
|---|---|
Your component interacts with remote databases, and its methods may be called by another component as part of a larger transaction. Multiple updates are issued before calling completeWork, or an update depends on the results of queries that were issued since the last call to completeWork. |
Requires Transaction or Requires New Transaction |
Updates from your component are performed by a single database update, the update logic is independent of any other query issued by the method, and you call completeWork in each method that issues an update. In other words, your component’s updates are already atomic. |
Supports Transaction |
Your component’s methods make intercomponent method calls, and the work done by called components must be included in one transaction. |
Requires Transaction or Requires New Transaction |
Methods in the component interact with more than one remote database, and updates to different databases must be grouped in the same transaction (this also requires a transaction coordinator that supports two-phase commit to those databases). |
Requires Transaction or Requires New Transaction |
Transactions begun by your component must not be affected by the outcome of transactions begun by other components that call your component. |
Requires New Transaction |
Work done by your component must never be done as part of a transaction. |
Not Supported |
For example, in the scenario illustrated in “A transaction involving multiple components”, the Enrollment component must be marked Requires Transaction or Requires New Transaction, since it calls methods in the Registrar and StudentBilling components, and the work performed by the called components must be grouped in a single transaction. Both Registrar and StudentBilling must be marked Supports Transaction or Requires Transaction so that their database updates can be grouped in the transaction begun by the Enrollment component.
Transaction Not Supported is useful when your component performs updates to a noncritical database. For example, consider a component whose sole function is to log usage statistics to a remote database. Since usage statistics are not mission-critical data, you can choose Not Supported as the component’s transaction type value to ensure that the logging updates do not incur the overhead of using two-phase commit.
