A transaction is a set of one or more SQL statements that
make up a logical unit of work that you can either commit or roll back and
that will be recovered in the event of a system failure.
All the statements in the transaction are atomic. A transaction
is associated with a single Connection object (and
database). A transaction cannot span Connections (or databases).
Derby permits schema
and data manipulation statements (DML) to be intermixed within a single transaction.
If you create a table in one transaction, you can also insert into it in that
same transaction. A schema manipulation statement (DDL) is not automatically
committed when it is performed, but participates in the transaction within
which it is issued. Because DDL requires exclusive locks on system tables,
keep transactions that involve DDL short.
- Transactions when auto-commit is disabled
When auto-commit is disabled, you use a Connection object's commit and rollback methods to commit or roll back a transaction.
- Using auto-commit
A new connection to a Derby database is in auto-commit mode by default, as specified by the JDBC standard.
- Turning off auto-commit
You can disable auto-commit with the Connection class's setAutoCommit method.
- Explicitly closing Statements, ResultSets, and Connections
You should explicitly close Statements, ResultSets, and Connections when you no longer need them.
- Statement versus transaction runtime rollback
When an SQL statement generates an exception, this exception results in a runtime rollback. A runtime rollback is a system-generated rollback of a statement or transaction by Derby, as opposed to an explicit rollback call from your application.
- Using savepoints
The Savepoint interface contains methods to set, release, or roll back a transaction to designated savepoints. Once a savepoint has been set, the transaction can be rolled back to that savepoint without affecting preceding work. Savepoints provide finer-grained control of transactions by marking intermediate points within a transaction.