Professional Visual Basic 6 MTS Programming

Chapter 4: Transaction Processing

In the last chapter, we took a rather detailed look at COM and NITS and saw what was going on behind those spinning balls. This chapter will be less intensive but no less important.

Up until this point, our focus has been on the Object Request Broker (ORB) features of MTS. But now it's time to turn our attention to the center of MTS, transactions. Transaction processing systems are nothing new. They have been around for decades. However, before the release of NITS, transaction processing had never been combined with object management, a very powerful combination for developing distributed, component-based, software systems.

After completing this chapter, you should, be able to answer the following questions:

• What is a transaction?
• What does ACID have to do with transactions?
• How can I change data in multiple databases and still meet the requirements of the ACID test?
• How is MS DTC a part of MTS?
• What is the difference between database transactions and MTS transactions?
• What are Resource Dispensers and how do they work?
• How does database connection pooling work?
• What are the different stages in the life of an NITS transaction?

Introduction to Transactions

The first recorded use for the word transaction occurred in Roman civil law around 1460, which was used to define an adjustment for a dispute. Transaction was borrowed directly from the Latin word transactionem, meaning an agreement or accomplishment. It was not until another 200 years or so, the word transaction evolved to reflect a sense of business.

Actually transactions have existed since man has roamed the earth. To betterunderstand transactions, let's go back in time some 2 million years ago and visit the original founder of the fictional Grog Company. Grog's first business transaction was with a local clansman named Borg. Grog admired Borg's collection of seashells. At the same time, Borg admired Grog's collection of beads. Grog offered to trade Borg five seashells for five beads. Borg accepted, and the trade was made. This is a transaction. Actually, being new at this transaction business, a few alternatives were tried first.

Grog in good faith first gave Borg five seashells. However, Borg decided to see what would happen by with-holding the delivery of beads to Grog and not keeping his end of the bargain. Grog beat Borg on the head with a woolly mammoth tusk and then took his seashells back.

Although Borg had a hard head, he was a quick learner and apologized to Grog. This time, Borg gave Grog the five beads in return for five seashells and the transaction was completed.

I don't have to tell you, but you know that software systems are not completely bulletproof Functionality errors within the software, as well as errors that are beyond the control of the developer, such as hardware or network failures, will eventually occur. Distributed component-based systems are even more prone to failure because of their increased complexity. With remote components, executing on the behalf of clients, which are modifying data stored in different data sources, many pieces of complex software and hardware must work together seamlessly. When an error does occur, data cannot be left in an inconsistent state. An entire set of operations or changes performed on one or more data sources must all succeed (commit) or all fail (roll back).

To accomplish this all-or-nothing work management that ensures data consistency and integrity, we use transactions.

A transaction is an operation or a series of operations that change data from one consistent state to another.

In other words, a transaction simply treats multiple operations as one unit of work. To better understand this, consider the famous banking transaction scenario:

An individual walks up to an ATM machine and proceeds to transfer $500 from their savings account to their checking account. Two operations are actually being performed with this transfer. $500 is being withdrawn from the savings account and the same $500 is being deposited into the checking account. These two operations must be performed as one unit of work or as a transaction.

Either both of these operations must succeed or both must fail. If either individual operation fails, the transaction as a whole is not successful and any work that was already performed must be rolled back or undone in order to maintain the integrity of the accounts. Imagine if the withdrawal of $500 from the savings account succeeded but the deposit of $500 dollars into the checking account failed for whatever reason. Not only would the balances of the accounts not be correct, but the bank also would not have a very happy customer.

While most of the time a transaction is composed of multiple operations or units of work, the general term transaction is used for just about any operation that modifies data. For this reason you'll sometimes hear a single operation being referred to as a transaction. Don't be confused.

A transaction can be composed of one or more operations, although most of the time a transaction is composed of multiple operations.

ACID Properties

A transaction is an action, or series of actions, that transform a system from one consistent state to another. Every transaction must meet the following four essential requirements, known collectively as the ACID properties:

• Atomicity
• Consistency
• Isolation
• Durability

Atomicity

Atomicity refers to the all-or-nothing proposition of a transaction that we mentioned earlier. Once a transaction is started, it will either commit or abort.

If all of a transaction's operations complete successfully, the transaction can commit and the changes made by all of the transaction's operations will remain. If any of the operations fail, the transaction will abort and any of the changes already made by its operations will be undone. There is no chance that some operations in a transaction complete and some operations will fail. For example, when Borg withheld his beads from Grog, Grog took back his seashells. This transaction was completely aborted. However, when Grog and Borg traded as agreed, the transaction was executed completely.

To provide the ability to rollback or undo uncommitted changes, many data sources implement a logging mechanism. For example, SQL Server uses a write-ahead transaction log where changes are written to the log before they are applied or committed to the actual data pages. However, other data sources which are not relational database management systems (RDBMS), manage uncommitted transactions completely differently. As long as the data source is able to undo any uncommitted changes, if a transaction is rolled back, the technique used by a data source for managing transactions doesn't really matter.

Although the all-or-nothing behavior is the first thing that comes to mind in a discussion about transaction processing, it is important to remember that the atomicity property is only one of the four ACID properties. A transaction must also meet the other three ACID properties.

Consistency

A transaction also must be consistent.

This means that every process that makes up a transaction cannot break any business rules or semantics specified by the environment.

In simpler terms, business logic for Grog's transaction needs to be consistent with every transaction Grog executes. When Grog agreed to trade five beads for five seashells, Grog did in fact receive five seashells. At the same time, he gave Borg five beads. The business logic in Grog's time is very simple: "x something" for "y something". Yet it shows that even 2 million years ago, transactions maintained consistency.

Consistency ensures that changes made as a result of a transaction do not violate the integrity of the data. For example, in our ATM banking transaction scenario, after the transfer of $500 from an individual's savings account to their checking account both accounts have to reflect the transfer. Individual operations within a transaction may leave the data in an inconsistent state because a transaction is about transforming data from one consistent state to another, however once a transaction is committed, a transaction must guarantee the consistency and integrity of the data in all the data sources affected.

Again, in our ATM banking scenario, both accounts are in a consistent state before the transfer. During the transfer, money is first withdrawn from the savings account. At this point the data is in an inconsistent state. $500 dollars has been withdrawn as part of a transfer and has not been accounted for in another account. However, the transaction is not yet complete. The same $500 is then deposited into the checking account. This operation effectively completes the transaction and both accounts are returned to a consistent state.

Data sources such as SQL Server, and other RDBMS, enforce data consistency and integrity through the use of constraints.

Applications or business components can also enforce data consistency and integrity, although it is usually recommended to implement this functionality at the data source level. This is to ensure that data consistency is enforced even when changes to the data are made outside of your application's or component's control.

Remember, a transaction is not responsible for enforcing data integrity, but instead a transaction is only responsible for ensuring that data is returned to a consistent state after the transaction is either committed or aborted. The burden of understanding data integrity rules and possibly writing code to enforce them usually falls on the shoulders of the developer who is creating business components, so be prepared.

Transactions must also maintain data consistency and integrity when multiple concurrent users are accessing and modifying the same data, a concept that goes hand in hand with the next ACID property, isolation.

Isolation

All of the operations performed in a transaction must be isolated from operations performed by other transactions.

This property is sometimes referred to as serializability because in order to prevent one transaction's operations for interfering with another's, requests must be serialized or sequenced so that only one request for the same data is serviced at a time.

Let's consider isolation in our ATM banking transaction scenario. At the exact time an individual is transferring $500 from the savings account to the checking account, his significant other, standing at another ATM machine, decides to withdraw $100 from their checking account. If one transaction is performed before the other, and the transactions are serialized, there will not be a problem. However, if the withdrawal of $ 100 from the checking account occurs during the $500 transfer, the balance of the checking will appear inconsistent. To the individual transferring the $500 from the savings to the checking account, it would appear that the checking account was short $ 100, but to the other person withdrawing $ 100 from the checking account the balance would appear as though it had gained $400. If concurrent transactions could modify the same data at the same time, rollbacks would produce inconsistent results.

Isolation not only guarantees that multiple transactions cannot modify the same data at the same time, but isolation also guarantees that changes caused by one transaction's operations will not be seen by another transaction until the changes are either committed or aborted. Concurrent transactions will be unaware of each other's partial and inconsistent changes. This means that all requests to modify or read data that is already involved in a transaction are blocked until the transaction completes. Most data sources such as SQL Server and other RDBMS implement isolation through the use of locks. Individual data items or sets of data are locked from concurrent access if it is involved in a transaction. ...