JAVA TRANSACTIONS

I have captured the important notes on Java Transactions through various reference across the web which may be useful to others to have quick refresh.

Transactions

ACID Model [ http://databases.about.com/od/specificproducts/a/acid.htm ]

basic building blocks of any database transaction model.

Automicity - Each transaction is said to be “atomic.”

Consistency - states that only valid data will be written to the database. 

Isloation - requires that multiple transactions occurring at the same time not impact each other’s execution.

Durability - ensures that any transaction committed to the database will not be lost. 

Two-Phase Commit [2PC]

In the first phase[Prepare/Commit-request/Vote phase], checks are made to see that the transaction ran without error. If there were no errors, the results are committed in the second phase[commit phase]. If there were errors in the first-phase check, the transaction is rolled back. This common transaction strategy is appropriately called the two-phase commit protocol.

http://www.java-tips.org/java-ee-tips/enterprise-java-beans/introduction-to-the-java-transactio.html

one-and-a-half phase commit [1.5PC] -  provide the 2PC-like atomicity for a database and a messaging resource, but without using XA.

Two types:

Programattic Transactions - using Spring's TransactionTemplate.

Declarative Transactions

·         Using advises to manage transactions.

·         Using Spring’s @Transactional annotation

Attributes in Spring's @Transactional Annotation

1. Isolation decides the level of isolation between transactions.

Isolation Level	Behavior
DEFAULT	Use the default isolation level of the underlying database.
READ_UNCOMMITTED	Allows a row changed by one transaction to be read by another transaction before any changes in that row have been committed. This means dirty reads, non-repeatable reads and phantom reads can occur. This is equivalent to Connection.TRANSACTION_READ_UNCOMMITTED. It is also the most efficient isolation level.
READ_COMMITTED	It prohibits a transaction from reading a row with uncommitted changes in it. This prevents dirty reads, but non-repeatable reads and phantom reads can occur. This is equivalent to Connection.TRANSACTION_READ_COMMITTED.
REPEATABLE_READ	It prohibits a transaction from reading a row with uncommitted changes in it, Dirty reads and non-repeatable reads are prevented; phantom reads can occur. This is equivalent to Connection.TRANSACTION_REPEATABLE_READ.
SERIALIZABLE	It prohibits dirty reads, non-repeatable reads and phantom reads. It prevent all problems but is the least efficient isolation level.

2. Propagation decides if method should execute within an existing/new or no transaction.

Propagation	Behavior
PROPAGATION_REQUIRED	Support a current transaction, create a new one if none exists.This is the default setting. If an existing transaction is in progress, method will run within that transaction, else a new transaction will be started.
PROPAGATION_SUPPORTS	Support a current transaction, execute non -transactionally if none exists.
PROPAGATION_MANDATORY	Support a current transaction, throw an exception if none exists.
PROPAGATION_REQUIRES_NEW	Create a new transaction, suspend the current transaction if one exists
PROPAGATION_NOT_SUPPORTED	Execute non - transactionally, suspend the current transaction if one exists.
PROPAGATION_NEVER	Execute non - transactionally, throw an exception if a transaction exists
PROPAGATION_NESTED	Method should run within a nested transaction if an existing transaction exists.The nested transaction can be committed/roll backed independently of the enclosing transaction. If no enclosing transaction behave like PROPAGATION_REQUIRED.

Propagation.REQUIRED is the default value.

3. Read only - If an operation does not modify the data in database, but simply reads it then a read-only transaction can be used. The default value is false.

4.Transaction timeout - To prevent long running transactions a timeout value can be set, which causes the transaction to rollback if it does not complete in the specified time. The default value is -1.

5. Rollback Rules - By default when a method throws a run-time exception, Spring will rollback the transaction. 

Internally who handles the transaction commit and rollback? Which API, which class?

Java.sql.Connection

Which library is responsible for transaction manager?

JTA

References:

http://docs.spring.io/spring/docs/1.2.4/reference/transaction.html