EJB transaction exception when deploying two ear in the same JBoss instance

[barakka]

Hi,

we have an application that is composed of two ear packaged project, each one containing EJBs, and in which the EJBs from one EAR call the EJBs of the other. The two ear point to separate databases and, for development, we are using HSQLDB with memory storage, configured with TCP access. The EJBs of the first ear access the others via their remote interfaces through remote JNDI lookup.

If we place the two EARs in separate instances of JBoss (and as such separate instances of HSQLDB) everything works.

When we deploy the two EARs in the same JBoss instance (an AS4.2.3) the EJBs from the second ear fail to join the transaction when invoked from the EJBs of the first EAR, due to the current transaction being in abort only state. In this scenario the two EAR use two (non-XA) datasources pointing to the same HSQLDB instance but different databases.

We are using an SMPC in both projects (injected with @In EntityManager) and we have not placed any transaction specific annotation on any EJB (should we?)

Any idea why this happens? Should we be using XA datasources? Does HSQLDB supports it? Any configuration example? And in any case, why it works when the code is really distributed and does not when it is only virtually distributed?

Thanks a lot,
Riccardo.

[asookazian]

By default, JSR 220 defaults to REQUIRED tx propagation type for public interface methods.  You can try using REQUIRES_NEW to see if that helps.  Not sure why you're using HSQLDB (unless it's for dev purposes only) and not sure if it supports XA or not (most likely not).

You need to you XA datasources whenever there is a distributed tx.  So that means in the same session bean method which requires a tx, you are performing EntityManager operations on two different datasources.

You are probly better off using MySQL for dev purposes or going straight to MSSQL or Oracle which definitely support XA...

[barakka]

Hi,

thanks for the replay. We in fact came to the same conclusion. And we had to move to MSSQL, as MYSQL does not offer complete support for XA (and JBoss was complaining). We have discovered, and I believe it was also mentioned in some thread recently, that JBoss is able to handle one XA and one non-XA datasource in the transaction, but not two non-XA ones.

What I'm really wondering is why JBoss was not complaining (loudly enough) when the two apps were deployed on two separate JBoss instances...