1.0

Table Of Contents
To the extent possible, model your database so that most transactions operate on colocated data. When all
transactional data is on a single member, then stricter isolation guarantees are provided.
Transaction Functionality and Limitations
Take note of transaction behavior and limitations in this release of SQLFire.
In this release of SQLFire, the scope for transactional functionality is:
The result set that is obtained from executing a query should either be completely consumed, or the result set
is explicitly closed. Otherwise, DDL operations wait until the ResultSet is garbage-collected.
Transactions for persistent tables are enabled by default, but the full range of fault tolerance is not yet
implemented. It is assumed that at least one copy of a row is always available (redundant members are available)
in the event of member failures.
SQL statements that implicitly place locks, such as select for update, are not supported outside of
transactions (default isolation level).
The supported isolation levels are 'READ COMMITTED' and 'READ UNCOMMITTED' where both behave
as 'READ COMMITTED.' Autocommit is OFF by default in SQLFire, unlike in other JDBC drivers.
Transactions always do "write-write" conict detection at operation or commit time. Applications do not need
to use select for update or explicit locking to get this behavior, as compared to other databases.
(select for update is not supported outside of a transaction.)
Nested transactions and savepoints are not supported.
SQLFire does not restrict concurrent non-transactional clients from updating tables that may be involved in
transactions. This is by design, to maintain very high performance when no transactions are in use. If an
application uses transactions on a table, make sure the application consistently uses transactions when updating
that table.
All DML on a single row is atomic in nature inside or outside of transactions.
There is a small window during a commit when the committed set is being applied to the underlying table and
concurrent readers, which do not consult any transactional state, have visibility to the partially-committed state.
The larger the transaction, the larger the window. Also, transaction state is maintained in a memory-based
buffer. The shorter and smaller the transaction, the less likely the transaction manager will run short on memory.
vFabric SQLFire User's Guide142
Developing Applications with SQLFire