XA Transactions

XA Transactions Atomic Transactions In database systems, atomicity (or atomicness) forms one of the ACID group of transaction properties. In an atomic transaction, a series of database operations either all occur, or all do not occur ("fail", although the model does not regard failure as catastrophic). A guarantee of atomicity prevents updates to the database occurring only partially, which can cause greater problems than rejecting the whole series outright.

XA Transactions Atomicity Example One example of atomicity comes from ordering airline-tickets. Potential passengers must either: both pay for and reserve seats on a flight; OR neither pay for nor reserve seats The booking-system does not treat it as acceptable for customers to pay for tickets without securing their requested flight or to reserve tickets without payment succeeding.

XA Transactions Orthogonality Atomicity does not behave completely orthgonality with regard to the other ACID properties of the transactions. For example, isolation relies on atomicity to roll back changes in the event of isolation failures such as deadlock; consistency also relies on rollback in the event of a consistency-violation by an illegal transaction. Finally, atomicity itself relies on durability to ensure the atomicity of transactions even in the face of external failures. As a result of this, failure to detect errors and manually roll back the enclosing transaction may cause failures of isolation and consistency.

XA Transactions Implementation Many databases also support a commit/rollback mechanism aiding in the implementation of atomic transactions. Databases usually implement this using some form of logging/journaling to track changes. The system synchronizes the logs (often the metadata) as necessary once the actual changes have successfully taken place. Afterwards, crash recovery simply ignores incomplete entries. Although implementations vary depending on factors such as concurrency issues, the principle of atomicity — i.e. complete success or complete failure — remain.

XA Transactions In database systems, isolation is a property that defines how/when the changes made by one operation become visible to other concurrent operations. Isolation is one of the ACID (Atomicity, Consistency, Isolation, Durability) properties.

XA Transactions The isolation property is the most often relaxed ACID property in a DBMS (Database Management System). This is because to maintain the highest level of isolation a DBMS must acquire locks on data, which may result in a loss of concurrency or else implement multiversioning (version control), which may require additional logic to function correctly.

XA Transactions Isolation Levels Most DBMSs offer a number of transaction isolation levels which control the degree of locking which occurs when selecting data. For many database applications the majority of database transactions can be constructed in such a way as to not require high isolation levels, thus reducing the locking overhead for the system. Conversely, at higher isolation levels the possibility of deadlock is increased, which also requires careful analysis and programming techniques to avoid.

XA Transactions Phantom Reads A phantom read occurs when, in the course of a transaction, two identical queries are executed, and the collection of rows returned by the second query is different from the first. This can occur when range locks are not acquired on performing a SELECT.

XA Transactions The isolation levels defined by the ISO standard are: SERIALIZABLE REPEATABLE READ READ COMMITTED READ UNCOMMITTED

XA Transactions SERIALIZABLE This isolation level specifies that all transactions occur in a completely isolated fashion; i.e., as if all transactions in the system had executed serially, one after the other. The DBMS may execute two or more transactions at the same time only if the illusion of serial execution can be maintained. At this isolation level, phanton reads cannot occur.With a lock-based concurrency control DBMS implementation, serialization requires that range locks are acquired when a query uses a ranged WHERE clause. When using non lock conncurrency control, no lock is acquired; however, if the system detects a concurrent transaction in progress which would violate the serializability illusion, it must force that transaction to rollback.

XA Transactions REPEATABLE READ All data records retrieved by a SELECT statement cannot be changed; however, if the SELECT statement contains any ranged WHERE clauses, phantom reads may occur. In this isolation level the transaction acquires read locks on all retrieved data, but does not acquire range locks.

XA Transactions READ COMMITTED Data records retrieved by a query are not prevented from modification by some other transaction. Non repeatible reads may occur, meaning data retrieved in a SELECT statement may be modified by some other transaction when it commits. Write locks are removed at commit.

XA Transactions READ UNCOMMITTED In this isolation level, dirty reads are allowed. One transaction may see uncommitted changes made by some other transaction.

XA Transactions Example Users Table id name age 1 joe 20 2 jill 25

XA Transactions Example Continued Transaction 1 /* Query 1 */ SELECT * FROM users WHERE age BETWEEN 10 AND 30;

Example Using Serializable XA Transactions Example Using Serializable Note that transaction 1 executed the same query twice. If the highest level of isolation were maintained, the same set of rows should be returned both times, and indeed that is what is mandated to occur in a database operating at the SQL SERIALIZABLE isolation level. However, at the lesser isolation levels, a different set of rows may be returned the second time. In the SERIALIZABLE isolation mode, Query 1 would result in all records with age in the range 10 to 30 being locked, thus Query 2 would block until the first transaction was committed. In REPEATABLE READ mode, the range would not be locked, allowing the record to be inserted and the second execution of Query 1 to return the new row in its results.

Two-phase commit protocol XA Transactions Two-phase commit protocol In computer network and databases, the two-phase commit protocol (2PC) is a distributed algorithm that lets all nodes in a distributed system agree to commit a transaction. The protocol results in either all nodes committing the transaction or aborting, even in the case of network failures or node failures.

Two-phase commit assumptions XA Transactions Two-phase commit assumptions The protocol works in the following manner: one node is designated the coordinator, which is the master site, and the rest of the nodes in the network are designated the cohorts. The protocol assumes that there is stable storage at each node with a write ahead log, that no node crashes forever, that the data in the write-ahead log is never lost or corrupted in a crash, and that any two nodes can communicate with each other.

Two-phase commit protocol initiation XA Transactions Two-phase commit protocol initiation The protocol is initiated by the coordinator after the last step of the transaction has been reached. The cohorts then respond with an agreement message or an abort message depending on whether the transaction has been processed successfully at the cohort.

XA Transactions Basic algorithm Commit Request Phase The coordinator sends a query to commit message to all cohorts and waits until it has received a reply from all cohorts. The cohorts execute the transaction up to the point where they will be asked to commit. They each write an entry to their undo log and an entry to their redo log. Each cohort replies with an agreement message (cohort votes Yes to commit), if the transaction succeeded, or an abort message (cohort votes No, not to commit), if the transaction failed.

Basic Algorithm (concluded)‏ XA Transactions Basic Algorithm (concluded)‏ Commit Phase Success If the coordinator received an agreement message from all cohorts during the commit-request phase: The coordinator sends a commit message to all the cohorts. Each cohort completes the operation, and releases all the locks and resources held during the transaction. Each cohort sends an acknowledgment to the coordinator. The coordinator completes the transaction when acknowledgments have been received. Failure If any cohort sent an abort message during the commit-request phase:

Two-phase commit protocol - Disadvantages XA Transactions Two-phase commit protocol - Disadvantages The greatest disadvantage of the two-phase commit protocol is the fact that it is a blocking protocol. A node will block while it is waiting for a message. This means that other processes competing for resource locks held by the blocked processes will have to wait for the locks to be released. A single node will continue to wait even if all other sites have failed. If the coordinator fails permanently, some cohorts will never resolve their transactions.