It refers to the 2 phase commit (tx manager calls prepare() first, and then commit() if all enlisted resources prepared() succesfully). Something that's needed in XA distributed transactions for instance.
It sounds as if somewhere in your transaction your enlisting non-XA resources. Did anything change in your code? Is PostgreSQL your only transactional resource that you're using? What drivers are you using with Postgres?
I do not know what XA / non-XA stands for (my apologies for my ignorance). As for datasources, what we did was leave JBoss as is with Hypersonic on the back end.
We added a second datasource of our own choosing that uses Postgres on the backend. Everything we deploy asks for our PGDB datasource by default, but if it does not exist, falls into the Hypersonic stuff.
The code worked fine on both datasources when they were both defined as default.
How does one enlist a "non-XA" resource?
Thank you for your help
I didn't anwser all your questions:
VERSION = 'PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.95.4'
Using JDBC: pgjdbc2.jar
I just tried this driver, and it looks like it performs faster than the one I was using. I just used the one that was built when I built postgres from the downloaded source. It was named postgresql.jar.
Would you expect the j2ee driver to be better? Due to the connection pool?
I haven't tested its performance. But I was getting some XA tx isolation errors from the pgjdbc2.jar driver before. So for me it works better.
I have inserted the 2ee driver and still receive the same error.
Is there something else I can read that would tell me where to look for the cause of the error? I don't know if its a descriptor, code, or jboss problem. The logs are useless (unless you know of a trick to turn on even more debug output for things, mainly the transaction manager).
I appreciate your help.
It is still not clear to me why it is requiring XA transactions if you're sure you are only using one datasource within a single transaction. You might want to overview the code and configuration changes one more time to make sure everything is correct, and only local transactions are required.
If not, you may have to create an XA datasource configuration for Postgres (don't have one for you, sorry). In the docs/jca/examples directory there are couple of examples of XA datasources to other databases (MS SQL, Oracle). You can look at those as an example. They use a different JCA adapter to connect to the JDBC datasource (jboss-xa.rar rather than jboss-local-jdbc.rar).
Humor me a moment please:
From your last comment I just came to the following conclusion. If, during a single JBoss transaction, I manage to access two separate datasources (ignoring the DBs transactioning), then JBoss will throw one of these LocalTx errors?
Why then do they allow you to specify a separate datasource on a bean basis if you want to? That to me would certainly cross over datasources within a single JBoss transaction.
Where can I read about this stuff? I still don't understand it well enough to ask intelligent questions.
> If, during a single JBoss transaction, I manage to
> access two separate datasources (ignoring
> the DBs transactioning), then JBoss will throw one of
> these LocalTx errors?
If your database drivers do not support 2 phase commit, yes. With two phase commit it is not a problem.
> Why then do they allow you to specify a separate
> datasource on a bean basis if you want to? That to
> me would certainly cross over datasources within a
> single JBoss transaction.
Basically two phase commit is saying that if you have accessed two separate data sources within the same transaction, the transaction manager needs to be sure they both will commit successfully before the transaction can be committed. If it calls commit() on the first datasource and then the commit() on the second one fails there's no way of rolling back the first commit().
That's why two phase commit calls prepare() first. If both datasources are able to prepare (basically saying they will be able to commit the transaction) then we know that the commit() on the transaction will succeed. Otherwise we rollback the transaction (there's no commit() on either datasource yet).
The warning you're seeing is a complaint that somewhere in your transaction you are not using the two phase commit protocol. One phase of the transaction will be committed, and if other parts of the transaction will fail (some other datasource fails) the non-XA (two phase) commit cannot be rolled back. So you are not getting the transaction semantics you would expect.