1 Reply Latest reply on Dec 2, 2009 4:06 AM by Galder Zamarreño

    How to manage an exception that occurs in the commit or roll

    Nicolas Filotto Novice

      Hi,

      I'm trying to ensure the integrity of my data thanks to the TransactionManager. However, I met an issue during my study, I noticed that if I implement my own CacheLoder and an error occurs during the commit phase, the TM is never aware of this error since the commit is done in the afterCompletion of TxInterceptor$RemoteSynchronizationHandler and the exception is eaten by this method. According to the JTA specification, the afterCompletion method is not supposed to notify the TM when something wrong occured but my questions are the following:
      1. Is-it normal that the commit is done in the afterCompletion? it should be done before the afterCompletion
      2. What are we supposed to do? Up to now, we decided to commit in the prepare phase which is done in the beforeCompletion method if an error occurs the TM is notified and can call the rollback method but is-there a better solution?

      Thank you in advance for your help,
      BR,
      Nicolas Filotto

        • 1. Re: How to manage an exception that occurs in the commit or
          Galder Zamarreño Master

          If you look at existing CacheLoader implementations such as JDBCCacheLoader, you'll see that we call cf.commit(tx);.

          cf.commit(tx) does not do anything in a managed environment, such as the JBoss Application server since it's the JBoss JCA layer that will make sure that anything that the datasource, or database, participates of the transaction correctly. We do the puts in the prepare() call which is called from beforeCompletion(). The datasource will then interact with the database and the underlying JDBC connection and do the corresponding transactional work.

          I think you're prepare/commit/rollback phases should be the same as the ones in JDBCCacheLoader or more precisely, parent AdjListJDBCCacheLoader.

          In an unmanaged connection or standalone mode, since the NonManagedConnectionFactory has direct access to the underlying java.sql.Connection, we do the commit there. I agree that errors arising here in an unmanaged environment could be an issue but we can't do anything about it because JBossCache is not a proper XA resource.

          One recommendation however would be that if you're using a JDBC-like cache loader, you should retrieve the connection from the ConnectionFactory we provide and let it do its job of interacting with the java.sql.Connection accordingly depending on whether it's in a managed environment or not.