Transaction Support

Recall from Chapter 9 that you can enclose a group of Actions within a Transaction shape. You can also declare the entire schedule as a transacted component by setting the properties of the Begin shape.

The XLANG Scheduler Engine manages the transactional integrity of a running schedule. This means that the effect of Actions enclosed by the Transaction either all occur or don't occur at all, and if they do occur, then the effects are never lost. The engine, therefore, checkpoints the entire state of the running schedule before and after a transaction. We looked at the state of the running schedule and how it is managed in the previous section “State Management.” With transactions, when Actions enclosed by the transaction exchange messages through ports, the engine must coordinate the transaction state with the state in the port implementations. We now look at how transactions are used with each of the implementation technologies.

For messaging services, using transactions is simpler. MSMQ queues can be created as transactional, and you can optionally specify whether transactions are required when exchanging messages with the queue. MSMQ queues that are transactional use MSMQ transactions when exchanging messages. If you specify for the bound port that transactions are required, then the attached queue must be transactional, or else the engine will failfast the schedule. BizTalk Messaging queues are transactional. Due to the “fire-and-forget” nature of messaging, an action completes when the message is delivered or received. A transaction must make this action atomic and durable. Further coordination activity needed for the transaction, should it fail, is only to undo the delivery or receipt of a message. This simplicity is also related to the reduced isolation level supported by Messaging Services—for example, a message read by an uncommitted transaction is not seen on the queue by others, although it might reappear if the transaction aborts. The internal state of the messaging service is not of much concern for transaction management.

For COM components, using transactions effectively requires you to be aware of many options. These options, for example, allow you to use transaction-unaware components in your schedule and to control the isolation level at a fine granularity. The following transaction support is available for COM or script components that are installed. The wizard used to set these options is described later in the sections “COM Component Binding Wizard” and “Script Component Binding Wizard.”

The following options are supported:

• Disabled— Applies to non-COM+ components. The component ignores COM transaction management.

• Not Supported— Applies to COM+ components. The component does not participate in transactions.

• Supported— Applies to COM+ components. If the XLANG Scheduler Engine has associated a transaction with the port, then the component can participate in that transaction context—the context flows through to the component. If no such transaction context is available, the component operates outside a transaction.

• Required— Applies to COM+ components. This is like the Supported option, except that if there is no transaction context available from the XLANG Scheduler Engine, the component creates a new one and operates within that context.

• Requires New— Applies to COM+ components. This states that the component always creates its own transaction context. This isolates the actions in the two contexts.

Notice that if a component is not installed in the COM+ environment, then from the point of view of the XLANG Scheduler Engine, transactions are disabled for it.

The default isolation level for COM+ configured components is serializable; however, you can specify a different isolation level as part of the Transaction properties, and this will override the COM+ setting. Note that, if a configured component calls a stored procedure, the isolation level and transaction context may be subverted by the stored procedure, causing unwanted behavior. Similarly, the transaction timeouts specified in the XLANG schedule override the default MSDTC settings.

See Chapter 9 for additional discussion of transactions and isolation levels. Chapter 9 also discusses the different kinds of transactions supported in an XLANG schedule. These are the short-lived DTC style transaction, long-lived transaction, and the timed transaction. The transaction attributes described in this section apply to the COM component and not to the XLANG transaction—they are primarily used with short-lived transactions.