distributed transactions with Seam/JBoss apps

[asookazian]

We are using Seam 2.0.0.GA for all our JavaEE app dev and deploying onto JBoss 4.2.1.GA AS.

We are running into situations where there are three db's used for CRUD operations in a single app. In this case, these db's are on the same server. However, b/c the transaction type defaults to REQUIRED for all EJB3 methods, transaction propagation is happening which is turning into a situation that requires XA datasource(s) to support 2PC. Please note that only one DB is being updated, the other 2 in this case are for read-only.

What is the recommendation here? I've read that XA can cause performance degradation. I'm being forced to alter usage of SMPC's (Seam Managed Persistence Contexts) as well as modify the transaction attributes for the EJB method annotations to get around transaction enlistment exceptions due to not having XA enabled/setup.

Also, if we have EJB1 method A that execs an update via JPA EntityManager to table A on DB1 and then another method in EJB1 is called that sends a JMS message, can we use XA (distributed) transaction for this situation?

In other words, the asynchronous message should not fire if the update rolls back...

thx.

[marklittle]

"asookazian" wrote:

We are running into situations where there are three db's used for CRUD operations in a single app. In this case, these db's are on the same server. However, b/c the transaction type defaults to REQUIRED for all EJB3 methods, transaction propagation is happening which is turning into a situation that requires XA datasource(s) to support 2PC. Please note that only one DB is being updated, the other 2 in this case are for read-only.

What is the recommendation here? I've read that XA can cause performance degradation.

Read-only optimization should kick in here so you'll only have one resource in the transaction in reality. Have you noticed any appreciable performance problems?

I'm being forced to alter usage of SMPC's (Seam Managed Persistence Contexts) as well as modify the transaction attributes for the EJB method annotations to get around transaction enlistment exceptions due to not having XA enabled/setup.

Also, if we have EJB1 method A that execs an update via JPA EntityManager to table A on DB1 and then another method in EJB1 is called that sends a JMS message, can we use XA (distributed) transaction for this situation?

As long as you have your JMS set up for XA support, then it should just work.

[asookazian]

What is read-only optimization exactly? Is this implying that you don't need XA in this case (e.g. 2 selects and 1 update on 3 db's)?

We have not attempted using XA datasources yet so as far as personal experience with performance degradation is concerned, that's an unknown.

Configuring MS SQL SERVER for XA capability requires a DLL install as well as XA sprocs to be installed. Not sure what is required for Oracle (we currently have both RDBMS vendors in our enterprise).

We have not attempted to setup JMS/JBossMQ for XA support yet either (I'm just planning/preparing for this in the future).

When you do introduce an XA datasource in your [fooBar]-ds.xml, I'm assuming it will be possible to use it as required. In other words, if your current method calls for a local transaction then you may use a local-tx-datasource which is linked to a different persistence unit in your persistence.xml. So mix and match as necessary is ok depending on whether you need local or distributed tx's?

[adinn]

What is read-only optimization exactly? Is this implying that you don't need XA in this case (e.g. 2 selects and 1 update on 3 db's)?

If a transaction only writes to one of the data sources then the read-only optimization bypasses the 2PC. It performs a single direct commit of the written data sources without involving the read-only data sources. This also avoids the need to log progress of the commit to persistent store.