Long-Lived Transactions It sounds like short-lived transactions do exactly what you ask them to do, so you may be wondering why you need long-lived transactions. Let's reexamine the previous schedule. You know that when a client document first arrives at the schedule, you'll update the database to indicate that the transactions in the document are in progress. Then you start processing the document with the trading component. Depending on the size of the transaction, some orders may not be fulfilled for a long time. For example, if a fund company decides to buy amillion shares of IBM, you really have no idea when the order can be fulfilled. It may take 3 minutes or 3 hours. If it indeed takes 3 hours to fulfill the order, do you really want to lock up the data you've updated (or read, depending on the isolation level) in the database so that no one else can read or update it? The answer is generally no. But what else can you do? As long as the trading component doesn't commit or abort, the database changes you made can't be committed or aborted either. Having too much data locked up for too long will dramatically degrade the performance of an application that depends on such data. To solve this problem, BizTalk Orchestration introduced a new type of transaction called a long-running transaction. (Timed transactions are almost the same as long-running transactions, as you'll see later.) The biggest difference between long-running transactions and short-lived transactions is that longrunning transactions aren't really transactions. Every action inside a long-running transaction will be committed or aborted as soon as it completes. When an action has been committed, the change is final and can't be rolled back regardless of whether other actions in the same long running transaction succeed or fail. The only difference between processes in long-running transactions and those without any transaction is that you can perform certain actions in the event of transaction failure. Here's the benefit of long-running transactions over short-lived transactions: Because everything is committed or aborted right away, the length of time locks are held on the data source is significantly reduced. For example, all the data that is updated by the Pre-Trade Database Update will become available for other applications immediately after the action completes. This means, though, that automatic rollback won't be available when the transaction aborts, since committed data can't be rolled back. To better understand the properties of a long-running transaction, let's modify the schedule you created earlier to include a long-running transaction (see Figure 10-12). Here you have a long-running transaction, and as with a shortlived transaction, you can define an On Failure page for it. Only the actions wrapped in the long-running transaction won't be rolled back automatically-for those actions you'll need to reverse the changes yourself on the On Failure of Long Tx page. Figure 10-12. The trade schedule with a long-running transaction Things are getting a little complicated with the short-lived transaction nested inside the long-running transaction in Figure 10-12. With nested transactions, you can delegate tasks that can be completed in relatively short time to shortlived transactions to take advantage of automatic rollback, and leave the tasks that take more time to run in the long-running transaction to take advantage of the faster release of resources. In a nested transaction, there are two Business Process pages that are used to handle the "on failure" situation. The first one is the regular On Failure page, and the second one is called the Compensation page, and both are specified in the Transaction Properties window (see Figure 10-13). Figure 10-13. Properties page for a short-lived transaction inside a long-running transaction When a short-lived transaction resides inside a long-running transaction, you can define a Compensation page on top of an On Failure page. In this case, you'll have a total of three "transaction failure" pages for the Long Tx transaction. There will be two On Failure pages for Long Tx and Trade Proc and one Compensation page for Trade Proc. The Compensation page is only called when the Trade Proc transaction has been committed but the Long Tx transaction is calling for an abort. The processes on the Compensation page are defined in exactly the same way as those of the On Failure page. Keep in mind that the actions in the corresponding transaction have been committed by the time the Compensation page is called, so actions that are taken on this page must reverse the changes that were committed. To test the new schedule, raise an error in the trading component, and watch it run in the XLANG Event Monitor. You should see the actions from the Compensation of Trade Proc page and from the On Failure of Long Tx page being called. Timed Transactions With long-running transactions, your trading component can run for hours without locking other data sources. However, at some point, you want to terminate the schedule. In such cases, you want to use timed transactions. The features and behavior of timed transactions are exactly the same as those of long-running transactions, except that you can define how long a transaction will run before it times out or aborts. With a timeout property, you can put a lid on how long a long-running transaction can run in the system.