10 Replies Latest reply on Jul 22, 2003 1:17 PM by juhalindfors

    What causes this?

    rdb55

      I've google'd and I've search through the forums here. I may not have been looking for the right thing, so a simple nudge in the right direction is satisfactory.

      What causes the following error to occur??

      09:26:23,811 WARN [LocalTxConnectionManager$LocalConnectionEventListener] prepare called on a local tx. You are not getting the semantics you expect!

      Our JBoss was working fine until we added a JAR and a few servlets. The worst part is, we initially had the JAR and servlets separate from the EAR that we normally use. No problems (at least we don't remember any), and then when we added it to the EAR we started to get this error. Its reaking havoc on our DB connections.

      Its as if every DB connection is being killed and never used. I've tried everything. We are using PostgreSQL on the back end and all the beans have the correct datasource and datasourcemapping applied to them.

      The only thing I found on google said this was related to a "double commit pattern" of some sort, of which I am not familiar.

      Any help is greatly appreciated!
      My thanks in advance,
      RDB

        • 1. Re: What causes this?

          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?

          • 2. Re: What causes this?
            rdb55

            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
            RDB

            • 3. Re: What causes this?
              rdb55

              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

              RDB

              • 4. Re: What causes this?

                Try using the J2EE driver instead: http://jdbc.postgresql.org/download/pg73jdbc2ee.jar

                This should support 7.2 as well.

                • 5. Re: What causes this?
                  nbirch

                  Hi,

                  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?

                  Thanks
                  NBirch

                  • 6. Re: What causes this?

                    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.

                    -- Juha

                    • 7. Re: What causes this?
                      rdb55

                      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.
                      RDB

                      • 8. Re: What causes this?

                        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).

                        -- Juha

                        • 9. Re: What causes this?
                          rdb55

                          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.

                          Thanks
                          RDB

                          • 10. Re: What causes this?

                            > 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.

                            See above.

                            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.

                            -- Juha

                            -- Juha