Jonathan Halliday commented on JBTM-496:
The new configuration parameter
com.arjuna.ats.coordinator.beforeCompletionWhenRollbackOnly, when enabled, will cause
beforeCompletion synchronizations to run as in versions prior to 4.6. The exact cases in
which beforeCompletion will be invoked are subtly different for the JTA and JTS and in the
latter case further complicated by the presence of the supportRollbackSync config option.
For 4.6 the beforeCompletionWhenRollbackOnly option is off by default, meaning the
beforeCompletions will be skipped in the manner expected by the EJB spec. This stands a
chance of breaking things that use beforeCompletion to do work other than flushing
updates, in which case it will be necessary to use the config option to force the old
style behaviour. For most apps though the new behaviour should show a small performance
make beforeCompletion sync behaviour configurable
Project: JBoss Transaction Manager
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: Configuration, JTA Implementation, JTS Implementation
Affects Versions: 4.5
Reporter: Jonathan Halliday
Assignee: Jonathan Halliday
Fix For: 4.6
The JTA and JTS/OTS specs are ambiguous with respect to the circumstances in which
beforeCompletion synchronizations should be invoked.
"The Synchronization.beforeCompletion method is called prior to the start
of the two-phase transaction commit process. This call is executed with the
transaction context of the transaction that is being committed."
"The beforeCompletion method is called by the transaction manager prior to the start
of the two-phase
transaction commit process. This call is executed with the transaction context of the
transaction that is being
Interestingly the change log for the JTA spec also includes this revision:
"Interface javax.transaction.Synchronization, method
beforeCompletion, change the following phrase in the description "start of
the transaction completion process" to "start of the two-phase transaction
which could be read as implying that beforeCompletion should not be called when a
transaction is being committed via a onePhase commit optimization. However, that
interpretation makes little sense and is accordingly rejected - beforeCompletions will
always be run before a xa resource commit in either phase.
Nevertheless, that still leaves open the question of the intended behaviour in cases such
as the sequence
In general we take the view that beforeCompletions are intended to allow cached data to
be flushed to stable store and thus invoking them when it is already known the transaction
cannot commit, is a waste of time. However, this is considered an optimization rather than
an absolute requirement.
A more extreme view appears to be taken by the EJB spec and testsuite, which expects the
beforeCompletion will definitely NOT run after a setRollbackOnly, although it seems to
have little basis for this assertion.
To allow for this ambiguity, the behaviour of the system should be configurable.
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see: http://www.atlassian.com/software/jira