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.
文章來源:
http://blog.csdn.net/Wingel/archive/2006/11/26/1414826.aspx