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.