[wildfly-dev] Issues accessing UserTransaction in WildFly

Scott Marlow smarlow at redhat.com
Wed Feb 26 11:04:37 EST 2014


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/TransactionSynchronizationRegistry.html#getTransactionStatus%28%29.
> 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/releases/org.jboss.seam/jboss-seam/2.2.2.Final/org/jboss/seam/persistence/ManagedPersistenceContext.java#118
>
> [3] http://grepcode.com/file/repository.jboss.org/nexus/content/repositories/releases/org.jboss.seam/jboss-seam/2.2.2.Final/org/jboss/seam/transaction/Transaction.java#77
>
> [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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>



More information about the wildfly-dev mailing list