As discussed on the call with Grant
PostTransactionWorkQueue sync: if we support TX in the backend, perform also the next operation in prepare.
To fully implement this approach we need to:
enlist the JMS message publication in the transaction (and not via autocommit)
move the execution of the backend from afterTransaction to beforeTransaction but after Hibernate ORM's flush so that the list of changes are complete but that the JMS messages are sent in the transaction.
offer an option of the JMS backend to use this transactional approach
make sure that if the transactional approach is used, all messages are sent in the same thread used by the main application (risk of transaction problems otherwise).
The attachement contains the code that enlist the JMS queue in the current transaction. Contributed by Yoann Gendre.
Considering points 1 and 4 are essentially done, we only need the option to change the backend execution to run within the transaction and some tests.
A note, we won't be able to mix transactional backends and non transactional backends in the same transaction because the Worker has to either do the processing work before or after the transaction. We don't feel the use case for mixed modes strong enough. We can revisit if someone comes with the requirement.