and again cause different results when the same ranged query is run twice
within the same transaction (known as phantom reads ).
Serializable— This is the highest level of isolation possible. Essentially it exe-
cutes all transactions in order, one after the other, so that there is no con-
flict among any one of them. Obviously this imposes a significant
performance penalty for highly concurrent systems, because everyone ends
up standing in line to complete their work.
A database that doesn't persist data in a durable way is like a bridge that doesn't
support the cars that drive on it. The ACID feature of durability requires that once
the database has reported a transaction as ending successfully, the results are safe.
Even if a system failure occurs after the transaction, the data should be safe.
Now that you're familiar with the basics of transactions and the qualities that
make them what they are, let's discuss how you work with various types of transac-
tions in i BATIS .
7.2 Automatic transactions
i BATIS only deals in transactions; it has no concept of ever working outside of a
transaction scope. So although JDBC has a concept of “autocommit” mode, i BATIS
does not support it directly. Instead, i BATIS supports automatic transactions. This
allows you to run a simple update statement or query with a single method call, and
without worrying about demarcating the transaction. The statement will still be
run inside a transaction, but you do not have to explicitly start, commit, or end it.
There's nothing special you need to do to run a statement within an automatic
transaction—you simply execute your statement. The configuration is the same as
for local transactions, which we discuss in the next section. Listing 7.1 shows how
this is done. Note that each statement is a separate transaction, including the calls
to queryForObject and update() .
public void runStatementsUsingAutomaticTransactions()
SqlMapClient sqlMapClient =
Person p = (Person)