1.1

Table Of Contents
Chapter 24
Using Distributed Transactions in Your
Applications
A transaction is a set of one or more SQL statements that make up a logical unit of work that you can commit or roll
back, and that will be recovered in the event of a system failure. SQLFire's unique design for distributed transactions
allows for linear scaling without compromising atomicity, consistency, isolation, and durability (ACID) properties.
Overview of SQLFire Distributed Transactions
All statements in a transaction are atomic. A transaction is associated with a single connection (and database)
and cannot span connections. In addition to providing linear scaling, the SQLFire transaction design minimizes
messaging requirements, so that short-lived transactions are efcient.
Main Features of the SQLFire Transaction Model on page 147
How the Transaction Model Works on page 147
Main Features of the SQLFire Transaction Model
The SQLFire transaction model uses these important features:
Each SQLFire member that participates in a transaction maintains its own transaction state. Queries on the
database always see committed data, and they do not need to acquire any locks; as a result, reads and writes
can occur in parallel in the READ_COMMITTED isolation level.
During transactional writes, SQLFire individually locks each copy of a row that is being updated on each
member. This alleviates the need for a distributed lock manager, and it allows for greater scalability.
Also, SQLFire uses special read locks for REPEATABLE_READ and foreign key checks to ensure that those
rows do not change for the duration of a transaction.
SQLFire locks generally fail eagerly (fail-fast) with a conict exception (SQLState: X0Z02) if a lock cannot
be obtained due to concurrent writes from other active transactions.
An exception to this fail-fast behavior occurs when the SQLFire member that initiates the transaction also hosts
data for the transaction. In this case, SQLFire batches the transaction on the local member for performance
reasons, and conicts may not be detected on other nodes until just before commit time when SQLFire ushes
the batched data.
SQLFire never batches operations for SELECT ... FOR UPDATE statements.
How the Transaction Model Works
When data is managed in partitioned tables, each row is implicitly owned by a single member for non-transactional
operations. However, with distributed transactions, all copies of a row are treated as being equivalent, and updates
are routed to all copies in parallel. This makes the transactional behavior for partitioned tables similar to the
147