WF from Getting started to proficient (15th chapter): Workflows and transactions

After completing this chapter, you will learn:

1. Understand the traditional transaction model and where it is suitable to use and where it is not suitable for use

2. The right time to know where it is not suitable for traditional affairs and when it is a matter of compensation

3. See how to roll back or compensate for the transaction

4. See how to modify the default compensation order

If you are writing software, sooner or later you will need to understand the transaction process. Transaction processing (transactional processing) in this sense is the writing of software that records information to a persistent resource, such as databases, Microsoft message queues (it uses a database at the bottom), Windows Vista with a transactional file system, registry access, or even some other software systems that support transaction processing. Persistent resources regardless of what happens, the written information is retained once the data is recorded.

Transactions are critical to any business process, because through transactions you can ensure the consistency of data in your application. If the business process maintains an error but persists some data, the wrong data is likely to ripple across the system, leaving you with the question of which data is correct and which data is wrong. Imagine ordering this book from an online merchant, but discovering that the merchant and your credit card transaction "had a little accident" and charged 100 times times the price of your book instead of their discounted price. When an error like this can occur, the transaction is no longer a ludicrous or evasive topic.

Understand the business

The core of transaction processing is managing your application state. For States, I actually refer to the status of all the data for the application. When all the data for an application is consistent, the application is in a determined state. If you add a new customer record to your database, the process requires two inserts (one is a new line record that usually contains the information that the address is associated with your customer). The other is to record the real address information), add the usual row record after success, but add its address failed, This causes your application to be in an indeterminate state. What happens when someone tries to retrieve the address? The system prompts that the address should be here, but the real address record has been lost. Your application data is now inconsistent.

To ensure that both operations are successful, the transaction works. A transaction itself is a single unit of work that either succeeds or fails all. This is not to say that you cannot update two different database tables. It just means that two-table updates are considered a single unit of work, and two must be updated or fail. If one or two of these updates fail, ideally you want the system to go back to the state that you just tried to update the tables. There is no indication that attempts to update these tables are successful, and your application should move on, but more importantly, you don't want to have data from one of the unsuccessful updates to the other.

Note: Books with full volume of written and related knowledge of transaction and transaction processing. While I'll describe the explanation of how Microsoft Windows Workflow Foundation (WF) supports transactional concepts deep enough, I can't cover all aspects of the transaction in this book in quite depth. You should do this if you haven't yet looked at the usual transaction support in. NET 2.0. WF's transaction mode and the. NET 2.0 transaction support are very close, and you can find useful knowledge in the following paper to understand WF's transactional support: Msdn2.microsoft.com/en-us/library/ms973865.aspx.

Traditionally, transactions derive from a single pattern: XA or two-phase commit (two-phase commit) types of transactions. However, with the advent of internet-based communications and the need to commit long-running transactions, new transaction types called compensating transactions are introduced. WF supports both of these types. We'll start with the traditional transaction, and then we'll talk about using this type of transaction as a low-level architectural choice, and then we'll discuss compensatory transactions.

Traditional (XA) transactions

The first known system to implement a transaction is an airline reservation system. For requests for multiple flights, if any single flight cannot be booked, the reservation cannot be made. System Designers know these and design a transactional approach that we call the X/open Distributed transaction processing model, called XA, today. (See En.wikipedia.org/wiki/x/open_xa.) ）

XA transactions involve the XA protocol, the two-phase commit and three entities I mentioned earlier: applications, resources, and transaction managers. An application is a program that refers to your application. A resource is a software system designed to be added to an XA type of transaction, meaning it participates in the transaction and knows how to participate in two-stage submission data and provide persistence (which will be discussed shortly). The transaction manager monitors the entire transaction process.

So what is a two-phase commit? Finally, imagine that your application needs to write data, which means a database. If the write process executes under a transaction, the database maintains the data to be written until the transaction manager issues a prepared (prepare) directive. At that time, the database responded with a vote (vote). If the vote is to move forward and submit the data to the table, the transaction manager enters and participates in the resource, if any.

If all resources have a successful vote on the submission data, the transaction manager issues a commit directive and each resource writes the data to its internal data store. It is only then that the data specified to be written to your table is actually inserted into the database.

The transaction manager issues a rollback (rollback) directive if any of the resources are problematic and the submission data is not voted on. All resources involved in the transaction must destroy the information related to the transaction, and nothing is saved by the permanent record.

Once the data is submitted, the XA protocol guarantees the durability of the transaction results. The data is consistent and the application is in a certain state.