[cdi-dev] CDI + transactions query

Pete Muir pmuir at bleepbleep.org.uk
Fri Aug 24 18:02:01 EDT 2012

On 24 Aug 2012, at 22:17, Jens Schumann wrote:

> Am 22.08.12 17:44 schrieb "Pete Muir" unter <pmuir at 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?

It certainly would, if we know what the right way to specify it is. If you know how to specify it, please please please please come up with a proposal (I suggest writing it on the issue) and then I can help you work out the spec changes.

> 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.

Ok, I'm no TX expert, so I need to rely on people who are, like you, and Tom et al from our TX team.

> 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.

Marina, now in cc, is JTA spec lead IIRC.


More information about the cdi-dev mailing list