Java Reference
In-Depth Information
Solution
A transaction's propagation behavior can be specified by the propagation transaction attribute. Spring
defines seven propagation behaviors, as shown in Table 4-6. These behaviors are defined in the
org.springframework.transaction.TransactionDefinition interface. Note that not all types of
transaction managers support all of these propagation behaviors. Their behavior is contingent on the
underlying resource. Databases, for example, may support varying isolation levels, which constrains
what propagation behaviors the transaction manager can support.
Table 4-6. Propagation Behaviors Supported by Spring
Propagation
Description
REQUIRED
If there's an existing transaction in progress, the current method should run within
this transaction. Otherwise, it should start a new transaction and run within its own
transaction.
REQUIRES_NEW
The current method must start a new transaction and run within its own transaction. If
there's an existing transaction in progress, it should be suspended.
SUPPORTS
If there's an existing transaction in progress, the current method can run within this
transaction. Otherwise, it is not necessary to run within a transaction.
NOT_SUPPORTED
The current method should not run within a transaction. If there's an existing
transaction in progress, it should be suspended.
MANDATORY
The current method must run within a transaction. If there's no existing transaction in
progress, an exception will be thrown.
NEVER
The current method should not run within a transaction. If there's an existing
transaction in progress, an exception will be thrown.
NESTED
If there's an existing transaction in progress, the current method should run within the
nested transaction (supported by the JDBC 3.0 save point feature) of this transaction.
Otherwise, it should start a new transaction and run within its own transaction. This
feature is unique to Spring (whereas the previous propagation behaviors have analogs
in Java EE transaction propagation). The behavior is useful for situations such as batch
processing, in which you've got a long running process (imagine processing 1 million
records) and you want to chunk the commits on the batch. So you commit every 10,000
records. If something goes wrong, you roll back the nested transaction and you've lost
only 10,000 records' worth of work (as opposed to the entire 1 million).
Search WWH ::




Custom Search