Enterprise Transaction Services—Transaction Attributes

Visual C# Tutorials

.NET Framework Tutorials

Enterprise Transaction Services Transaction Overview Programmatic Transactions Automatic Transactions Transaction Attributes Transaction Streams Transaction Outcomes ContextUtil Methods Automatic Transaction Example Transactional Vote AutoComplete Attribute Distributed Transactions Transactions Without Components ASP.NET Transactions Support Transaction Isolation Monitoring the DTC .NET 2.0 Transactions Summary

© 2005 Pearson Education, Inc.

Transaction Attributes

The [Transaction] attribute that can be applied to classes that implement serviced components has five different values that you can set with the enumeration TransactionOption. The values of the enumeration TransactionOption are Required, RequiresNew, Supported, NotSupported, and Disabled. Table 7-1 describes what these values mean.

Table 7-1 TransactionOption Enumeration

TransactionOption Value	Description
Required	The value Required marks that the component needs a context with a transaction. If the context of the calling object does not have a transaction, a new transaction is started inside a new context. If the calling object does have a transaction, the same transaction from the calling object is used.
RequiresNew	Similar to the value Required, with RequiresNew the component always gets a context with a transaction; but contrary to Required, a new transaction is always created. The transaction is always independent of a possible transaction of the calling object.
Supported	The value Supported means that the component is happy with or without a transaction. This value is useful if the component does not need a transaction itself, but it may invoke components that do need transactions, and it may be called by components that have already created transactions. Supported makes it possible for a transaction to cross the component, and the calling and called components can participate in the same transaction.
NotSupported	If the component is marked with NotSupported, the component never participates in a transaction. If the calling object does not have a context with a transaction, it can run inside the same context. If the calling object does have a context with a transaction, a new context is created.
Disabled	The option Disabled differs from NotSupported insofar as the transaction in the context of the calling component is ignored.

The meaning of the transaction values you can set with the attribute [Transaction] 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.

Table 7-2 TransactionOption Behaviors

Attribute	Calling Component Running in a Transaction	Running in a Transaction	Running in a New Transaction
Required	Yes	Always	No
	No		Yes
RequiresNew	Yes	Always	Always
	No
Supported	Yes	Yes	Never
	No	No
NotSupported	Yes	Never	Never
	No
Disabled	Yes	Yes, if calling context is shared	Never
	No	No

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, object 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 value NotSupported, and object C again has the value Required. Because object B 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 of object 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 B and C. If the database access fails with object C, a rollback with object A occurs, 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, object B is marked with the transactional configuration RequiresNew (a new transaction is required).