Version 18

    Why Do I Get "WARN Prepare called on a local tx."?

     

    The complete warning message is probably more close to this:

     

    18:56:47,578 WARN [TxConnectionManager] Prepare called on a local tx. Use of local
    transactions on a jta transaction with more than one branch may result in inconsistent
    data in some cases of failure.
    

     

    This is because your transactional resource (for example, your JDBC Datasource) does not support two phase commit protocol.

     

    The following could occur during the commit (in this example both JMS and JDBC resources participate in the same global transaction where the JMS resource supports two phase commit protocol and the JDBC resource does not):

     

    1. JMS: prepare (vote ok)

    2. JDBC: prepare (this is a no-op since the JDBC resource does not support two phase commit protocol)

    3. JMS: commit (guaranteed to work since it was prepared ok)

    4. JDBC: commit (might fail)

     

    This is bad, as the JMS branch of the transaction commit worked but the database commit failed.

     

    -


     

    JBoss 4.0 Update:

    Current CVS HEAD contains a "Last Resource Gambit" workaround for this problem that orders the resources so that a single local resource is committed last after all XA resources have been prepared. This works if only one local resource is involved in the global transaction with other XA resources.

     

    See this wiki for further details http://wiki.jboss.org/wiki/Wiki.jsp?page=PrepareCalledOnALocalTx

     

    -


     

    Postgre SQL Two Phase Commit Protocol Support

     

    PostgreSQL is one of the popular Open Source databases that does not currently support two phase commit protocol. Therefore, if you are using Postgre SQL as your database in a global transaction involving more than one resource it is likely that you see the warning mentioned above.

     

    UPDATE : PostgreSQL does now support two phase commit, as of Postgres 8.1.

    Two-Phase Commit (2PC): long in demand for WAN applications and heterogeneous data centers using PostgreSQL, this feature allows ACID-compliant transactions across widely separated servers.