The dialog shows the following fields:
■ Transaction Model This field can have two values:
■ Include Transaction within XLANG Schedule, meaning that the XLANG schedule controls the use of transactions.
■ Treat the XLANG Schedule as a COM+ Component; or the
XLANG schedule engine. Since an instance of a schedule is hosted by a COM+ application, also referred to as the schedule engine, the execution of the schedule takes place within the context of this COM+ application.
■ Transaction activation This field is only active if you choose Treat the XLANG Schedule as a COM+ Component as a transaction model. The values are:
■ Not supported The XLANG schedule will never run as a COM+ transaction.
■ Supported The XLANG schedule will only run as a transaction if the COM+ component that activated the schedule runs within a transaction.
■ Required The XLANG schedule needs to run in a COM+ transaction. If the COM+ component that activated the schedule does not run within a transaction a new transaction is created. In case a transaction is already active, the XLANG schedule will run in that transaction context.
■ Requires New The COM+ component will start a new transaction in which the XLANG schedule will run, even if the COM+ component is already running in a transaction.
■ XLANG Identity This is a read-only field that displays the unique identifier of the current XLANG schedule drawing. Every time you save the drawing, a new identifier is generated. This enables you to match the drawing version with a compiled version of the schedule. If these do not match, the compiled version is based on another version of the XLANG schedule drawing.
When you decide to use the COM+ transaction mode, you can no longer use transactions within your XLANG schedule drawings.You can draw them, but the drawing will not compile.
Developing & Deploying...
When working with databases, you know that applications need to modify data in different databases or database tables in an "all or nothing" manner. Because these multiple database actions are part of one (business) transaction, it would render the database inconsistent if only a part of these actions were executed. Therefore, in case one of the modifications fails, the others need to be undone (rolled back). This is the only way to keep the database(s) consistent. This is the classic way of a transaction that is defined by the ACID attributes:
■ Atomicity Stands for the "all or nothing" approach of the transaction. It has to be guaranteed that all modifications are committed or that all the modifications made during the transaction are undone.
■ Consistency When a transaction starts, the database is in a consistent state, and as the transaction is committed or rolled back, the database is left in a consistent state.
■ Isolation When more than one transaction is running concurrently, their modifications to the database are isolated from each other, as long as they are not committed. From the viewpoint of the transaction, it is the only one using the database. Concurrently running transactions leave the database in the same state as if they where running one after the other, also called serialization.
■ Durability The modifications to the database made by the transaction are permanent once the transaction is committed. Even a database failure cannot result in a modification becoming lost.
The database logs play an important role in enforcing ACID. For example if a severe database failure occurs and an older (consistent) version of the database has to be restored, the database logs can be used to replay the transactions, bringing the database to a consistent state just before the failure occurred. This replay is also called "roll-forward."
Within BizTalk Server, only the "short-lived, DTC-style" transaction has all these attributes. The long-running transaction fails to comply with any of the four attributes, especially isolation.
A good rule of thumb is that the longer a transaction takes to finish, the less likely it is that it can persist ACIDity, without locking out other applications/transactions. Why? Because once a database modification is used by another application/transaction, it cannot be rolled back.
The database transaction coordinator (DTC) always sits in between the application and the database(s), thus coordinating reads and writes to a database by multiple transactions, and coordinating reads and writes to more databases by one transaction, thereby enforcing ACID. In the latter situation, it will take care that on a rollback of a transaction, all modifications made to the databases involved are undone. Isolation is an attribute that the DTC supports at different levels. Let's first look at the different levels, and then explain what they are about:
■ Read Uncommitted A DTC transaction running at this isolation level is able to read all records in a database even if those records are written to by other transactions and these writes are not yet committed. This is the lowest level of isolation possible by the DTC.
■ Read Committed A transaction running at this isolation level is able to read only records that are not written to, thus where the writes are already committed. After the transaction has read the record, another is allowed to change it. This is the default isolation level of SQL Server 2000.
■ Repeatable Read A read committed, but now no record that is read by the transaction can be changed by another transaction, until the first transaction finishes. This is done to guarantee that when the record is read more than once by the transaction, it will return the same result.
■ Serializable A repeatable read, but extended to the level that when a query is run multiple times within the same transaction, it must return the same result. This can be the best explained by the following example: You perform a query on a bank account table to determine the total number of bank accounts that are held by the customers from the state of Massachusetts, and what their total balance is. If you ran this query twice within the same transaction, it must return the same result. Therefore, not only can the read records not be changed, but any bank account of Massachusetts customers can be added or removed.
Only serializable is the thorough level of isolation; exactly what you want in a transaction. So, why the other isolation levels? Because serialization prevents other transactions from accessing these records, so they have to wait for the transaction to end, before it is their turn to access the records. This affects the performance of applications. Isolation is directly related to the locking mechanism of the database, but explaining that goes way beyond the scope of this book. However, if you get increasingly involved in application development projects, you should read into the more technical details of the databases. A good source is Designing SQL Server 2000 Databases for .NET Enterprise Servers (Syngress Publishing, ISBN: 1-928994-19-9).
Let's get back to the subject. To increase performance, you need to increase concurrency, thus more transactions having access to the same records. You do this by claiming the lowest isolation necessary for your transaction, since many transactions do not need serializable isolation. Second, you release your claim (lock) on records as soon as you do not need them anymore. If every transaction adheres to these two points— lowest necessary isolation and minimizing claim on records—every transaction, thus application, will benefit.
Serializable isolation is also about locking records you want to read, and every lock that a database has to set costs time. So, why bother about a lock if the chance that a change takes place is minimal (read uncommitted)? Or, you can accept the fact that records can change, except while you want to read that record a single time (read committed).
However, as the results of queries become more important, you need to isolate data records from other transactions and accept less performance. Repeatable read will lock larger numbers of records for longer periods, using page locks, which is more efficient than locking individual records; hence, less performance loss. Serializable will use index locking, or when the number of records becomes so large, it will lock the whole table.
With the setting of the isolation level, you can influence the efficiency with which your XLANG schedule short-lived transaction uses databases.
In the rest of the section, we will discuss the different transaction types that the XLANG schedule supports in more detail.The sidebar "The Meaning of Transactions and the DTC" explains what transactions are about and which role the distributed transaction controller (DTC) plays.We encourage you to read it, since this information enhances the understanding of the discussion of XLANG
schedule transactions. Placing the transaction on your Business Process page is easy, and tying a part of the flow to the transaction is straightforward. However, using the transaction in a proper manner, especially if you are using a nested transaction, requires an understanding of what the transaction does during runtime. Let us first look at placing part of your flow in a transaction:
1. Start with an empty drawing, and drag an Action and End shape onto the page. Connect Begin with Action1, and Action1 with End. This drawing will not compile because there is no connection with an Implementation shape; that's OK, we do not want to compile it anyway.
2. Drag the Transaction shape onto the page, overlaying Action1.As you will notice, Actionl will be placed on top of the Transaction shape, together with the connection arrows. If you compiled now, you would get an error message telling you that the transaction is not properly connected.
3. Notice that there is a connection point (a blue cross) at the top and bottom of the Transaction shape, meaning that it has one entry and one exit point. This means that:
■ The connection arrow of the shape before the transaction has to be connected to the transaction entry point.
■ A connection has to be made from the transaction entry point to the first shape inside the transaction.
■ The connection of the last shape within the transaction has to be connected to the transaction exit point.
■ A connection has to be made from the transaction exit point to the first shape outside the transaction.
4. Before you do this, first select the Transaction1 and move it to another position on the page, keeping it to the left of the separator. Notice that every object enclosed by the Transaction shape also moves! Why? Because BizTalk Schedule Designer already made the assumption that every object within the transaction enclosure will be part of the transaction. Only the compiler needs these explicit connection points.
5. Because the compiler always wins, we will satisfy its needs. Select the connection arrow between Begin and Action1. Move the mouse pointer over connection point of Action1 (now represented by a red solid box). As the mouse pointer changes to a crossed arrow, press the left mouse button and keep it pressed while you move the mouse to the entry point of Transaction!., as it turns into a red square, release the mouse button. Connection made, just as you expected! Do the same with the other connection arrow. Now Actionl is 'floating' within the transaction, so you need to connect it with the beginning and end of the connection.
Was this article helpful?