NOTE: The transaction will have been committed or rolled back already, but the transactional resources might still be active and accessible. As a consequence, any data access code triggered at this point will still "participate" in the original transaction, allowing to perform some cleanup (with no commit following anymore!), unless it explicitly declares that it needs to run in a separate transaction. Hence: Use PROPAGATION_REQUIRES_NEW
for any transactional operation that is called from here.
@param status completion status according to the STATUS_*
constants
@throws RuntimeException in case of errors; will be logged but not propagated(note: do not throw TransactionException subclasses here!)
@see #STATUS_COMMITTED
@see #STATUS_ROLLED_BACK
@see #STATUS_UNKNOWN
@see #beforeCompletion
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|