Enterprise Transaction Services—Transaction Attributes
[Transaction] attribute that can be applied to classes that implement serviced
components has five different values that you can set with the enumeration
The values of the enumeration
Disabled. Table 7-1 describes what
these values mean.
| || The value |
| || Similar to the value |
| || The value |
| || If the component is marked with |
| || The option |
The meaning of the transaction values you can set with the attribute
is greatly influenced by the context of the calling component. Table 7-2
helps make this behavior more clear. In this table, all five transaction values are listed with both variants, whether the calling component is running inside a transaction
or not. Column 3 shows whether the component is running in a transaction,
and column 4 shows whether the component is running in a new transaction.
|Attribute|| Calling Component Running
in a Transaction
|Running in a Transaction||Running in a New Transaction|
| ||Yes||Yes, if calling context is shared||Never|
Supported or NotSupported?
I’m often asked, "Why should a component be marked with
Supported to support
transactions, although the component does not need transactions itself?"
Figures 7-4 and 7-5 describe why the transactional value
Supported is a useful
option. In both figures, three objects that call each other are shown. In Figure 7-4,
Ahas the transactional option
Required, and because the client does not have
a transaction, a new transaction is created. Object
B is marked with the transactional
NotSupported, and object
C again has the value
Required. Because object
does not support transactions, the context of object
B does not have a transaction
associated. When object
C is called by object
B, a new transaction is created. Here
the transactions of object
A and object
C are completely independent. The transaction
C may commit, whereas the transaction of object
A may be aborted.
Figure 7-5 shows a similar scenario but with object
B marked with the transactional
attribute Supported. Here the transaction from object
A is propagated to
C. If the database access fails with object
C, a rollback with object
because both objects are running inside the same transaction.
Required or Requires New?
With the transactional value
Required, a new transaction is created if a transaction
does not already exist in the calling object. If the calling object has a context with a
transaction, the same transaction is used. Under some scenarios, a different behavior
is required. For example, if object
A in Figure 7-6 changes a course map, but object
B writes the information to a log database, writing the information to the log should
happen independently if the transaction with object
A succeeds. To make this possible,
B is marked with the transactional configuration
RequiresNew (a new
transaction is required).