1.0

Note: Because the outcome of the transaction is assured at commit time, the coordinator does not wait
for individual commit replies from the cohorts before returning the committed transaction to the initiating
thread. If the same connection immediately initiates another operation on the same data, then the cohorts
wait for pending replies from the previous transaction (as described in Step 3) before applying the change.
SQLFire Transaction Design
SQLFire implements optimistic transactions. The transaction model is highly optimized for colocated data, where
all of the rows updated by a transaction are owned by a single member.
SQLFire avoids the use of a centralized distributed lock manager and the traditional 2-phase commit protocol.
Transactional state is managed on each data store that is affected by the transaction, using only local locks. This
allows the cluster to scale even when applications utilize transactions.
SQLFire uses an "eager lock, fail fast" algorithm that capitalizes on the fact that updates are reliably and
synchronously propagated to all cohorts (mainly replicas). The main ideas behind this algorithm are summarized
as follows:
• Acquire eager locks. Each transactional write operation is synchronously propagated to each replica where a
local transaction coordinator acquires a LOCAL write lock on the key.
• Fail fast. If the write lock cannot be acquired, presumably due to a concurrent, conflicting transaction, then the
write backs off and marks the transaction for rollback. The transaction outcome cannot be reversed.
• Transaction state. All the changes in a transaction are maintained on every member affected by the transaction
(every member that hosts a copy of a row changed in the transaction) in a transaction state. The changes are
applied locally to the underlying table data only on commit. This allows readers to execute concurrently with
a single writer without requiring any locks or blocking in the READ_COMMITTED isolation level.
The focus for this design is on "optimistic transactions" and the design makes these important assumptions:
• The typical transaction duration is short.
• Conflicts between transactions are rare. If concurrent transactions tend to conflict, it is the application's
responsibility to retry the failed transaction.
Using this design provides the potential for linear scaling. Without centralized lock management, transaction
throughput can easily scale with additional members. Transaction processing involves the data stores plus a
coordinating peer. Thus if the concurrent transaction workload is uniformly spread across the data set, increasing
the number of data stores also balances the workload and increases the aggregate transaction throughput.
The design also removes the colocation restriction for the transactional working set, because transactions can
involve any number of data hosts. Transaction performance is also increased, as compared to transactions that
use a centralized lock manager.
Best Practices for Using Transactions
For optimum results, take note of best practices for working with SQLFire transactions.
• For high performance, mimimize the duration of transactions to avoid conflicts with other concurrent transactions.
If atomicity for only single row updates is required, then completely avoid using transactions because SQLFire
provides atomicity and isolation for single rows without transactions.
• Unlike in traditional databases, SQLFire transactions can fail with a conflict exception on updates instead of
on commit. This choice makes sense given that the outcome of the transaction has been determined to fail.
• When using transactions, keep the transaction duration and the number of rows involved in the transaction as
low as possible. SQLFire acquires locks eagerly, and long-lasting transactions increase the probability of
conflicts and transaction failures.
141
Using Distributed Transactions in Your Applications