Re: [wildfly-dev] Issues accessing UserTransaction in WildFly

On 02/26/2014 02:02 AM, Jaikiran Pai wrote: > >> Right the real question is what is Seam using the UT for. There is > only one method on that is “safe” with CMT (getting the status), and > that isn’t all that useful. > > Looking at that stacktrace [1] and the code in Seam [2], it appears that > Seam wants to register a transaction synchronization if a transaction is > active. Unfortunately, a lot of libraries (including Seam) use the > UserTransaction API (UserTransaction.getStatus()) to check if a > transaction is active. The right way to do it is using the > TransactionSynchronizationRegistry which is available and portable (as > mandated by spec) under the java:comp/TransactionSynchronizationRegistry > JNDI name. The TransactionSynchronizationRegistry has a > getTransactionStatus() method which can be used to check the transaction > status in the current (thread) context > http://docs.oracle.com/javaee/5/api/javax/transaction/TransactionSynchron.... > Usage of this API is rarely explained and applications/libraries keep > using UserTransaction instead. > > To answer the other question as to why this started showing up now and > not in earlier versions, the code in Seam tries to deal with this exact > situation by catching a specific (NameNotFoundException) while doing a > UserTransaction lookup [3]. Notice that in that code [3], it doesn't > deal with any other exception other than NameNotFoundException although > that code does realize that using UserTransaction for what it's doing > can run into problems (the comments there indicate something along those > lines). So my guess is that, in previous version of AS, we used to throw > a NameNotFoundException in this specific case and now we are throwing a > IllegalStateException [4]. Maybe in WildFly, to prevent existing > libraries like Seam from breaking, we could just change this bit to > throw NameNotFoundException instead of IllegalStateException (although I > don't remember if the TCK tests for the exact exception type in this case). Should we catch the ISE somewhere in [5] and throw a NameNotFoundException (with the ISE as the cause) instead of the ISE? I wonder if we did that before in the AS5/AS6 naming code.

[5] at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:142) at org.jboss.as.naming.ServiceBasedNamingStore.lookup(ServiceBasedNamingStore.java:81) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:202) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:179) at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:235) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:188) at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:184) at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] at javax.naming.InitialContext.lookup(InitialContext.java:411) [rt.jar:1.7.0_51] at org.jboss.seam.transaction.Transaction.getUserTransaction(Transaction.java:82)[jboss-seam.jar:2.2.2.Final] > > > [1] > > at org.jboss.seam.transaction.Transaction.instance(Transaction.java:39) [jboss-seam.jar:2.2.2.Final] > at org.jboss.seam.persistence.ManagedPersistenceContext.joinTransaction(ManagedPersistenceContext.java:120) [jboss-seam.jar:2.2.2.Final] > at org.jboss.seam.persistence.ManagedPersistenceContext.getEntityManager(ManagedPersistenceContext.java:112) [jboss-seam.jar:2.2.2.Final] > > > [2] http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... > > [3] http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/... > > [4] Caused by: java.lang.IllegalStateException: JBAS014237: Only session and message-driven beans with bean-managed transaction demarcation are allowed to access UserTransaction > > P.S: A big congratulations on the WildFly 8.0 Final release! :) Although haven't posted here so far, I've been lurking this list. Good luck with the next releases. Big congratulations to you also Jaikiran, you are always part of the team! :) Thanks for helping with this issue! Scott > > > -Jaikiran > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev