transaction in Spring

Propagation behavior:

PROPAGATION_MANDATORY:
 Indicates that the method must run within a transaction. If no
 existing transaction is in progress, an exception will be thrown.

PROPAGATION_NESTED:
 Indicates that the method should be run within a nested transaction
 if an existing transaction is in progress. The nested transaction
 can be committed and rolled back individually from the enclosing
 transaction. If no enclosing transaction exists, behaves like
PROPAGATION_REQUIRED:
 Beware that vendor support for this propagation behavior is spotty at best.
 Consult the documentation for your resource  manager to determine if nested
 transactions are supported.
PROPAGATION_NEVER:
 Indicates that the current method should not run within a transactional
 context. If there is an existing transaction in progress, an
 exception will be thrown.
PROPAGATION_NOT_SUPPORTED:
 Indicates that the method should not run within a transaction. If an
 existing transaction is in progress, it will be suspended for the
 duration of the method. If using JTATransactionManager,
 access to TransactionManager is required.
PROPAGATION_REQUIRED:
 Indicates that the current method must run within a transaction. If
 an existing transaction is in progress, the method will run within
 that transaction. Otherwise, a new transaction will be started.
PROPAGATION_REQUIRES_NEW:
 Indicates that the current method must run within its own transaction.
 A new transaction is started and if an existing transaction is in
 progress, it will be suspended for the duration of the method. If
 using JTATransactionManager, access to Transaction-
 Manager is required.
PROPAGATION_SUPPORTS:
 Indicates that the current method does not require a transactional
 context, but may run within a transaction if one is already in
 progress.

Isolation levels:
In a typical application, multiple transactions run concurrently, often working
with the same data to get their job done. Concurrency, while necessary, can lead
to the following problems:
 ■ Dirty read—Dirty reads occur when one transaction reads data that has
 been written but not yet committed by another transaction. If the
 changes are later rolled back, the data obtained by the first transaction
 will be invalid.
 ■ Nonrepeatable read—Nonrepeatable reads happen when a transaction performs
 the same query two or more times and each time the data is different.
 This is usually due to another concurrent transaction updating the
 data between the queries.
 ■ Phantom reads—Phantom reads are similar to nonrepeatable reads. These
 occur when a transaction (T1) reads several rows, then a concurrent transaction
 (T2) inserts rows. Upon subsequent queries, the first transaction
 (T1) finds additional rows that were not there before.

Isolation level:
ISOLATION_DEFAULT:
 Use the default isolation level of the underlying datastore.
ISOLATION_READ_UNCOMMITTED:
 Allows you to read changes that have not yet been committed. May
 result in dirty reads, phantom reads, and nonrepeatable reads.
ISOLATION_READ_COMMITTED:
 Allows reads from concurrent transactions that have been committed.
 Dirty reads are prevented, but phantom and nonrepeatable
 reads may still occur.
ISOLATION_REPEATABLE_READ:
 Multiple reads of the same field will yield the same results, unless
 changed by the transaction itself. Dirty reads and nonrepeatable
 reads are prevented by phantom reads may still occur.
ISOLATION_SERIALIZABLE:
 This fully ACID-compliant isolation level ensures that dirty reads,
 nonrepeatable reads, and phantom reads are all prevented. This is
 the slowest of all isolation levels because it is typically accomplished
 by doing full table locks on the tables involved in the transaction.