Pete Muir wrote:
On 24 Aug 2012, at 22:17, Jens Schumann wrote:
> 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?
>
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.
You can mark a transaction for rollback inside the beforeCompletion
callback.
BeforCompletion callback is part of the transaction commit process, so
it's too late to request a commit. Nested transactions are not required
to be supported, but you should be able to suspend/resume an active
transaction to run a RequiresNew logic.
AfterCompletion callback is called after all transaction processing has
been finished.
> 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.
Paul Parkinson is (cc-ed) ;)
-marina
Thanks!