Am 22.08.12 17:44 schrieb "Pete Muir" unter <pmuir(a)bleepbleep.org.uk>:
>Admittedly this is a gut reaction, I read through the Jira and the
doc
>you linked to though, and used my JEE experience to draw analogies, do
>let me know if I got the wrong end of the stick please!
No, I think this is right.
In that case, what I would suggest we do is:
* explicitly make controlling transactions from observers non-portable
(which allows implementors to experiment with such a feature without
breaking spec compliance)
* raise a feature request in CDI to consider adding something like what
you describe in the future
Maybe I misunderstand the current wording, but wouldn't it be possible to
explicitly specify certain scenarios? For instance I would expect that
IN_PROGRESS (and maybe BEFORE_COMPLETION) observers and their dependencies
should be able to start and commit/rollback a new transaction (RequiresNew
semantics).
On the other hand I would also expect that AFTER_COMPLETION/AFTER_FAILRE
observers and their dependencies may never directly initiate, commit or
rollback JTA transactions.
I tried to find a few more answers to this in the current JTA/JTS specs.
However both specs are very thin in this regard. Do you know who can
answer which limitations apply to JTA Transaction Synchronization
beforeCompletion/afterCompletion callbacks? The JTA spec 3.3.2 has no
answer.
Jens