3 Replies Latest reply on Apr 2, 2002 10:44 PM by James Cook

    Transaction Context - Not Supported

    James Cook Newbie

      We have some session bean methods that we cannot run within a transaction. (It seems Sybase has some problems with the creation of temporary tables within a transaction.) To side-step this issue, we are choosing to mark these methods as "Not Supported".

      In these methods we grab a database connection from the jBoss pool. Shouldn't database resources grabbed from the pool in a non-transactional context have auto-commit set to true? Otherwise, when we execute our stored procedure, it will fail due to the implied transaction on the JDBC connection.

        • 1. Re: Transaction Context - Not Supported
          James Cook Newbie

          Looking at the source code, the XAManagedConnection class sets the autocommit to false for the JDBC connection during the getConnection() method. I suppose I can safely set autocommit to true, when I am running inside of a method that I don't want to execute within a transactional context. I say "safely" because the pool will set autocommit back to false when the connection is doled out again.

          This is very kludgey, methinks. jBoss's pooling mechanism should set autocommit to false in getConnection() _only_ if the current thread context is operating in a transactional context. Can this be added to 3.0?

          • 2. Re: Transaction Context - Not Supported
            David Jencks Master

            Yes, the jca spec specifies autocommit behavior very like what you describe, and it is not currently implemented in the jca-jdbc wrappers. It might possibly be in the sun blackbox examples, I haven't looked. It will get into jboss eventually.

            Meanwhile, can't you avoid the problems by calling conn.commit after every sql statement?

            • 3. Re: Transaction Context - Not Supported
              James Cook Newbie

              Setting auto-commit to true when getting a connection does not work, at least for Sybase. I believe it is because the same connection is reused by other database calls before the method that is flagged as "Not Supported". I suppose the answer is to not dole out a connection that is already involved in a transaction when the method is flagged as "not supported".