Note that isolation level and timeout settings will not get applied unless
an actual new transaction gets started. As only PROPAGATION_REQUIRED,
PROPAGATION_REQUIRES_NEW and PROPAGATION_NESTED can cause
that, it usually doesn't make sense to specify those settings in other cases.
Furthermore, be aware that not all transaction managers will support those
advanced features and thus might throw corresponding exceptions when given
non-default values.

The read-only flag applies to any transaction context,
whether backed by an actual resource transaction or operating non-transactionally
at the resource level. In the latter case, the flag will only apply to managed
resources within the application, such as a Hibernate Session.

PROPAGATION_SUPPORTS

static final int PROPAGATION_SUPPORTS

Support a current transaction; execute non-transactionally if none exists.
Analogous to the EJB transaction attribute of the same name.

NOTE: For transaction managers with transaction synchronization,
PROPAGATION_SUPPORTS is slightly different from no transaction
at all, as it defines a transaction scope that synchronization might apply to.
As a consequence, the same resources (a JDBC Connection, a
Hibernate Session, etc) will be shared for the entire specified
scope. Note that the exact behavior depends on the actual synchronization
configuration of the transaction manager!

In general, use PROPAGATION_SUPPORTS with care! In particular, do
not rely on PROPAGATION_REQUIRED or PROPAGATION_REQUIRES_NEWwithin a PROPAGATION_SUPPORTS scope (which may lead to
synchronization conflicts at runtime). If such nesting is unavoidable, make sure
to configure your transaction manager appropriately (typically switching to
"synchronization on actual transaction").

PROPAGATION_REQUIRES_NEW

static final int PROPAGATION_REQUIRES_NEW

Create a new transaction, suspending the current transaction if one exists.
Analogous to the EJB transaction attribute of the same name.

NOTE: Actual transaction suspension will not work out-of-the-box
on all transaction managers. This in particular applies to
JtaTransactionManager,
which requires the javax.transaction.TransactionManager to be
made available it to it (which is server-specific in standard Java EE).

A PROPAGATION_REQUIRES_NEW scope always defines its own
transaction synchronizations. Existing synchronizations will be suspended
and resumed appropriately.

PROPAGATION_NOT_SUPPORTED

static final int PROPAGATION_NOT_SUPPORTED

Do not support a current transaction; rather always execute non-transactionally.
Analogous to the EJB transaction attribute of the same name.

NOTE: Actual transaction suspension will not work out-of-the-box
on all transaction managers. This in particular applies to
JtaTransactionManager,
which requires the javax.transaction.TransactionManager to be
made available it to it (which is server-specific in standard Java EE).

Note that transaction synchronization is not available within a
PROPAGATION_NOT_SUPPORTED scope. Existing synchronizations
will be suspended and resumed appropriately.

PROPAGATION_NESTED

static final int PROPAGATION_NESTED

Execute within a nested transaction if a current transaction exists,
behave like PROPAGATION_REQUIRED otherwise. There is no
analogous feature in EJB.

NOTE: Actual creation of a nested transaction will only work on
specific transaction managers. Out of the box, this only applies to the JDBC
DataSourceTransactionManager
when working on a JDBC 3.0 driver. Some JTA providers might support
nested transactions as well.

ISOLATION_READ_UNCOMMITTED

This level allows a row changed by one transaction to be read by another
transaction before any changes in that row have been committed (a "dirty read").
If any of the changes are rolled back, the second transaction will have
retrieved an invalid row.

ISOLATION_REPEATABLE_READ

static final int ISOLATION_REPEATABLE_READ

Indicates that dirty reads and non-repeatable reads are prevented;
phantom reads can occur.

This level prohibits a transaction from reading a row with uncommitted changes
in it, and it also prohibits the situation where one transaction reads a row,
a second transaction alters the row, and the first transaction re-reads the row,
getting different values the second time (a "non-repeatable read").

ISOLATION_SERIALIZABLE

This level includes the prohibitions in ISOLATION_REPEATABLE_READ
and further prohibits the situation where one transaction reads all rows that
satisfy a WHERE condition, a second transaction inserts a row
that satisfies that WHERE condition, and the first transaction
re-reads for the same condition, retrieving the additional "phantom" row
in the second read.

getIsolationLevel

Must return one of the ISOLATION_XXX constants defined on
this interface. Those constants are designed
to match the values of the same constants on Connection.

Exclusively designed for use with PROPAGATION_REQUIRED or
PROPAGATION_REQUIRES_NEW since it only applies to newly started
transactions. Consider switching the "validateExistingTransactions" flag to
"true" on your transaction manager if you'd like isolation level declarations
to get rejected when participating in an existing transaction with a different
isolation level.

Note that a transaction manager that does not support custom isolation levels
will throw an exception when given any other level than ISOLATION_DEFAULT.

Note that a transaction manager that does not support timeouts will throw
an exception when given any other timeout than TIMEOUT_DEFAULT.

Returns:

the transaction timeout

isReadOnly

boolean isReadOnly()

Return whether to optimize as a read-only transaction.

The read-only flag applies to any transaction context, whether backed
by an actual resource transaction (PROPAGATION_REQUIRED/
PROPAGATION_REQUIRES_NEW) or operating non-transactionally at
the resource level (PROPAGATION_SUPPORTS). In the latter case,
the flag will only apply to managed resources within the application,
such as a Hibernate Session.

This just serves as a hint for the actual transaction subsystem;
it will not necessarily cause failure of write access attempts.
A transaction manager which cannot interpret the read-only hint will
not throw an exception when asked for a read-only transaction.