[wildfly-dev] Issues accessing UserTransaction in WildFly

Eduardo Martins emartins at redhat.com
Tue Feb 25 07:13:40 EST 2014


That’s wrt invoking EJBContext#getUserTransaction() only, but your first quote section has an additional paragraph:

"The enterprise bean’s business methods, message listener methods, business method interceptor meth- ods, lifecycle callback interceptor methods, or timeout callback methods must not attempt to obtain or use the javax.transaction.UserTransaction interface.”

The rule is too restrictive in my opinion, there is no harm in obtaining the UserTransaction I think, the restriction should be in using some of it’s methods, the same way restrictions are applied to the methods of the java.sql.ConnectionIt’s listed in your first quote.

Anyway, the spec is what it is, I don’t think Seam should try to change it. If there is enough utility in transaction control by Seam then it should clearly define how it integrates with Java EE. If there isn’t, if it’s just a matter of getting some status from transaction control, then alternatives should be used, such as the TSR. Well, Seam could also give some “room” to the app, and use the TSR for any status retrieval, leaving the usage of the Java EE UserTransaction for managing Seam's transaction, somehow IMHO “fixing" the spec.  

—E

On 25 Feb 2014, at 02:44, Scott Marlow <smarlow at redhat.com> wrote:

> Hmm, looks like I was looking at the wrong EJB spec section.  Should of been looking at:
> 
> "
> 8.6.3.10 Handling of getUserTransaction Method
> 
> If an instance of an enterprise bean with container-managed transaction demarcation attempts to invoke the getUserTransaction method of the EJBContext interface, the container must throw the java.lang.IllegalStateException.
> "
> 
> The pull request https://github.com/wildfly/wildfly/pull/3213 has more context about what happened (we used to throw the ISE pre-AS7, AS 7.0 didn't throw the ISE and we are now throwing it again).
> 
> org.jboss.seam.transaction.Transaction.getUserTransaction() shouldn't be used in a CMT.  I'm not sure of how to avoid that (perhaps some Seam configuration?)
> 
> On 02/24/2014 08:55 PM, Jason T. Greene wrote:
>> Yes this is an application requirement. You can't use CMT and call commit!
>> 
>> Sent from my iPhone
>> 
>>> On Feb 24, 2014, at 2:27 PM, Scott Marlow <smarlow at redhat.com> wrote:
>>> 
>>> Is the below requirement for the application or the container?
>>> 
>>> "
>>> 8.3.4 Enterprise Beans Using Container-Managed Transaction Demarcation
>>> 
>>> This subsection describes the requirements for the Bean Provider of an
>>> enterprise bean using container-managed transaction demarcation.
>>> 
>>> The enterprise bean’s business methods, message listener methods,
>>> business method interceptor methods, lifecycle callback interceptor
>>> methods, or timeout callback methods must not use any resource-manager
>>> specific transaction management methods that would interfere with the
>>> container’s demarcation of transaction boundaries. For example, the
>>> enterprise bean methods must not use the following methods of the
>>> java.sql.Connection interface: commit, setAutoCommit, and rollback; or
>>> the following methods of the javax.jms.Session interface: commit and
>>> rollback.
>>> "
>>> 
>>> IMO, I think that the requirement is on the application code and not the
>>> container.
>>> 
>>>> On 02/24/2014 02:44 PM, Eduardo Martins wrote:
>>>> This may be interesting to discuss here, please have a look at
>>>> 
>>>> https://issues.jboss.org/browse/WFLY-2936
>>>> 
>>>> Other issues that are related and I’m aware
>>>> 
>>>> https://issues.jboss.org/browse/WFLY-1168
>>>> https://issues.jboss.org/browse/WFLY-2960
>>> 
>>> I'm waiting to hear back from the Spring user but think that they will
>>> likely be able to solve it via existing Spring support for JTA.  For the
>>> Spring case, the user might not of noticed the (using UT in CMT) problem
>>> if it was just a warning but we can't have it both ways.
>>> 
>>>> 
>>>> —E
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> 
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 




More information about the wildfly-dev mailing list