A Review of Transactions As you saw, there are two transaction models for XLANG Schedules: COM+ component-style transactions and XLANG-style transactions. Only with XLANG-style transactions can you define short-lived, long-running, and timed transaction types. Short-lived transactions are DTC-style transactions, and they give you the benefit of automatic rollback when the transactions abort, but they also have the shortcomings associated with DTC transactions, such as locking up data for extended periods, which could hurt the performance of other applications accessing the same data. Long-running transactions solve the data-locking problem by committing the changes as soon as each action in the transaction completes, but you have to provide your own rollback logic for when the transaction aborts. When a short-lived transaction is nested inside a long-running transaction, two pages are called when the process aborts: The On Failure page defines actions that will be called when the short-lived transaction fails, and the Compensation page defines the actions that will be called when the short-lived transaction is committed and the surrounding long-running transaction is aborted. Timed transactions are simply long-running transactions with a timeout limit. Using XLANG Schedule Throttling Schedule throttling is a new feature in BizTalk Server 2002. It makes your BizTalk application scalable and also solves a very real problem. Let's use the trade schedule as an example. When clients send a document to Bob's BizTalk Server for processing, the XLANG engine will start an instance of the schedule and will start loading the components to process the document. What happens when Bob's client tries to send several documents at once? For example, the news of a federal interest-rate hike was just released, and every client reacts to the news and starts buying or selling stocks. Bob's ASP will receive over 50 trade orders at once. How will BizTalk Server react to these sudden demands? If you don't control how many trade schedules can run at once, BizTalk Server will attempt to start 50 trade schedules, and each of the schedules will attempt to instantiate all the components it needs to process the document. Having so many schedules running at once will significantly degrade the performance of every schedule running on the machine. The situation will become worse if the components used in the schedule are also making database reads or modifications. You can run into problems when the maximum number of database connections is reached. The performance of the database will also significantly degrade because the database server is overwhelmed with managing so many data locks at once. The result is that all the schedules are running on the system, but none of them are getting any work done. What you need is a way to manage how many instances of a particular schedule can run at one time so that BizTalk Server won't be overwhelmed by a huge number of running schedules. The solution to this problem is XLANG Schedule throttling or pooling, which allows you to specify the maximum number of instances of a specific schedule that can run at one time. To enable and configure this feature, open the schedule in Orchestration Designer, and open the Properties page of the Begin shape (see Figure 10-14). Figure 10-14. Configuring an instance pool for an XLANG Schedule By default, the value selected in the Pool list box is None, which means schedule pooling isn't enabled for this XLANG Schedule. Change this value to a pool number-for the purposes of this example, select Pool 1. Click OK to save the changes. This is the only thing you need to do in the schedule. Next, open Component Services. Under COM+ applications, locate the XLANG Schedule Pool application, and then expand its Components folder (see Figure 10-15). Under the XLANG Schedule Pool are 25 components. Each component will control the instance pooling for an XLANG Schedule. The default maximum number of instances for each of these components is 25, and you can modify these through the activation property of the components. Note that there are only 25 components under the XLANG Schedule Pool application. This number can't be changed. Figure 10-15. XLANG Schedule Pool application To configure the XLANG Schedule pooling application, open the properties page for SimpleSkedPool.SimplePool1.1, which corresponds to the Pool 1 setting you selected on the Begin shape of the schedule (see Figure 10-16). Figure 10-16. Configuring the pooling properties for the XLANG Schedule On the properties page, select the Activation tab. Check the Enable object pooling checkbox and the Enable Just In Time Activation checkbox. Set the maximum pool size to 5 to specify that a maximum of five running instances of the trade schedule can exist on the system at one time. Click OK to save the changes. To test the configuration, add some code to the trading component so that it will take longer to complete (for instance, put a msgbox function in the code so that it requires user interaction before proceeding). Then open the XLANG Event Monitor (see Figure 10-17). Now start ten trade schedules by dropping ten copies of the document in the folder that is watched by the Receive Function that starts the trade schedule. Only five instances will run on the system at once. Figure 10-17.With pooled XLANG Schedules, you can limit the number of schedule instances running at one time. If you look into the Queues folder in the BizTalk Server Administration Console, there will be five trade documents waiting in the Work Queue folder to be picked up as soon as a free spot becomes available in the schedule pool. As soon as a schedule instance is completed, a spot in the pool will become free for the next schedule instance. In Bob's case, when 100 trade documents arrive, the BizTalk XLANG engine will process the documents 5 at a time, and the system resources won't be overloaded by the excessive outstanding schedule instances.