COM+ 1.0 handles transaction isolation very conservatively. COM+ 1.0 only allows the highest level of isolation, an isolation level called serialized. With serialized transactions, the results obtained from a set of concurrent transactions are identical to the results obtained by running each transaction serially. Such a high degree of isolation comes at the expense of overall system throughput; the resource managers involved have to hold onto both read and write locks for as long as a transaction is in progress, and all other transactions are blocked. However, you may want to trade system consistency for throughput in some situations by lowering the isolation level. Imagine, for example, a banking system. One of the requirements is to retrieve the total amount of money in all customer accounts combined. Although executing that transaction with the serialized isolation level is possible, if the bank has hundreds of thousands of accounts, it may take quite a while to complete. The transaction may time out and abort because some accounts may be accessed by other transactions at the same time. But the number of accounts could be a blessing in disguise. On average, statistically speaking, if the transaction is allowed to run at a lower isolation level, it may get the wrong balance on some accounts. However, those incorrect balances would tend to cancel each other out. The actual resulting error may be acceptable for the bank’s need.
COM+ 1.5 allows you to configure the isolation level for a transactional component. The Transactions tab has a drop-down list box with five isolation levels (see Figure B-13). The available isolation levels are Any, Read Uncommitted, Read Committed, Repeatable Read, and Serialized. The default is set to Serialized.
The underlying transaction processing monitor, the DTC, supports other transaction isolation levels besides Serialized, but COM+ 1.0 passes in a hard-coded isolation level of Serialized when it creates a new DTC transaction. All COM+ 1.5 does to expose these levels is pass the configured isolation level, instead of the original hard-coded Serialized level in COM+ 1.0, to the DTC.
Selecting an isolation level other than Serialized is commonly used for read-intensive systems. It requires a solid understanding of transaction processing theory and the semantics of the transaction itself, the concurrency issues involved, and the consequences for system consistency. A good starting point is the bible on transaction processing: Transaction Processing: Concepts and Technologies by Jim Gray and Andreas Reuter (Morgan Kaufmann, 1992). In addition, not all resource managers support all levels of isolation, and they may elect to take part in the transaction at a higher level than the one configured. Every isolation level besides Serialized is susceptible to some sort of inconsistency resulting from having other transactions access the same information. The difference between the four isolation levels is in the way they use read and write locks. A lock can be held only when the transaction accesses the data in the resource manager, or it can be held until the transaction is committed or aborted. The former is better for throughput; the latter for consistency. The two kinds of locks and the two kinds of operations (read/write) give four isolation levels. See a transaction-processing textbook for a comprehensive description of isolation levels.
In a COM+ transaction, the root does more than just start and end a
transaction. It also determines the isolation level for the
transaction. Once determined, the isolation level is fixed for the
life of the transaction. A component cannot take part in a
transaction if the isolation level it requires is greater than that
of the transaction. Consequently, every component in a transaction
must have its isolation level set to a level equal to or less than
that of the root component. If a component in a transaction tries to
create another component with a greater isolation level, COM+ 1.5
refuses to create the component and CoCreateInstance( ) returns
CO_E_ISOLEVELMISMATCH
.
When isolation is set to Any, the component is indifferent to the isolation level of the transaction it is part of. If that component is not the root of a transaction, then it simply assumes the isolation level of the transaction it is part of when it accesses resource managers. If that component is the root of a transaction, then COM+ 1.5 decides on the isolation level for it and uses Serialized.
As a result, any component with isolation set to Serialized or Any can be the root of a COM+ 1.5 transaction because by definition, all other components have isolation levels equal to or less than they do. Any other isolation level for a root may not guarantee successful activation of internal components. The COM+ 1.5 Explorer displays a warning message when you change isolation level from Serialized or Any, which is almost correct in its content (see Figure B-14).
Figure B-14. Warning message when changing the isolation level from Serialized or Any to another level
It is possible for one component to call another component with a higher configured isolation level, as long as the transaction isolation is greater than or equal to that higher level. For example, Component R with isolation set to Repeatable Read is the root of a transaction, and it creates two other components, A and B, with isolation levels of Read Committed and Read Uncommitted, respectively. Component B can call Component A because the isolation level of A and B is less than that of the root R.
The correct warning message should read: “Changing this level from Serialized or Any requires that when this component is the root of a transaction, all components in the transaction have an isolation level less than or equal to the isolation level set for this component.”
You can also set the component’s isolation level
programmatically by setting the
TxIsolationLevel
named property of a component catalog
object.