That would also seem to be a very confusing choice. If the user
understands how the new annotation works, then applying it to an
EJB would give very different behavior. If they understood that
the behavior was going to be different with EJBs, then they would
probably also understand that they should use the EJB annotations.
Note also that many of the issues you point out for #3 may also be
issues if an EJB calls another component that uses transactions.
Pete Muir wrote on 02/02/12 04:49:
> Some feedback on this proposal, including another option.
>
> I'll try to provide more feedback as it comes in.
>
> Begin forwarded message:
>
>> From: Stuart Douglas<sdouglas_at_redhat.com>
>> Subject: Re: [javaee-spec users] [jsr342-experts] EJBs and JTA transactional interceptors
>> Date: 1 February 2012 23:44:26 GMT
>> To: Shane Bryzak<sbryzak_at_redhat.com>
>> Cc: Pete Muir<pmuir_at_bleepbleep.org.uk>, Dan Allen<dallen_at_redhat.com>, Jason Porter<jporter_at_redhat.com>, Lincoln Baxter<lbaxter_at_redhat.com>
>>
>> 7) If @Transactional is applied to an EJB treat it exactly the same as @TransactionAttribute.
>>
>> I think this is by far the simplest option, and is least likely to confuse the user.
>>
>> My objections to the other proposals:
>>
>> 2) As stated below this would be very surprising.
>>
>> 3) This will also give confusing behaviour:
>>
>> e.g. if the user specified @Transactional(NEVER) on an EJB this would always fail, as the EJB's default REQUIRED behaviour would mean that a TX would always be active. Stating that the user should just use @TransactionAttribute(SUPPORTS) to effectively disable CMT is not a good solution, as a user that understands why this is necessary will in all likelihood just use the @TransationAttribute annotations anyway.
>>
>> There is also the potential for a lot of other weird behaviour, even when specifying @TransactionAttribute(SUPPORTS). For consider what happens if a method has @Transaction(REQUIRES_NEW) and an invocation is made on the method that is already associated with an existing transaction. The EJB CMT interceptor will think that the EJB's work is being done in the outer transaction, when in fact it is happening in the inside transaction that was started by the JTA interceptor. If this then throws an exception the outer exception will still be rolled back, even though the EJB did not actually do any work in this transaction.
>>
>> We also need to consider the transaction behaviour of SFSB's, which basically have a transaction scoped lock that is released on TX commit, calling the SFSB's SessionSynchronization methods. In the case above the SFSB will be doing work in a different transaction to the one it is enlisted in.
>>
>> 4) My objections to #3 apply here as well.
>>
>> 5) Same here, just because the CMT mode is set to SUPPORTS it does not eliminate weird interactions between the CMT and JTA interceptors.
>>
>> 6) Same here as well, I also don't really think that the EJB exception rules should be modified, they are already confusing enough.
>