1 2 Previous Next 25 Replies Latest reply on Sep 9, 2002 1:46 PM by duslow Go to original post
      • 15. Re: Setting the AutoCommit JDBC property in 3.0.1RC1
        duslow

        You mentioned this in a previous post:


        The main difference in behavior I can think of right now is that in 3.0 you should get autocommit behavior outside an explicit transaction.


        I did two tests with a stateless session bean that just aquired a Sybase connection from the LocalTx datasource pool and then logged the state of the TransactionManager and whether autocommit was true or false on the datasource connection.

        With <transaction-type>Bean</transaction-type>, the TransactionManager state was STATUS_NO_TRANSACTION and autocommit was set to true on the datasource connection. This was the expected behaviour, and jibes with your statement.

        I then tried <transaction-type>Container</transaction-type> and then set all methods to Required. The TransactionManager state was STATUS_ACTIVE and autocommit was still set to true. I would have thought that autocommit would be set to false when the datasource is aquired inside the scope of a Container managed bean transaction. Otherwise, how would the LocalTx Manager explicitly rollback and/or commit against a datasource that has autocommit turned on?

        • 16. Re: Setting the AutoCommit JDBC property in 3.0.1RC1
          duslow

          You mentioned this in a previous post:


          The main difference in behavior I can think of right now is that in 3.0 you should get autocommit behavior outside an explicit transaction.


          I did two tests with a stateless session bean that just aquired a Sybase connection from the LocalTx datasource pool and then logged the state of the TransactionManager and whether autocommit was true or false on the datasource connection.

          With <transaction-type>Bean</transaction-type>, the TransactionManager state was STATUS_NO_TRANSACTION and autocommit was set to true on the datasource connection. This was the expected behaviour, and jibes with your statement.

          I then tried <transaction-type>Container</transaction-type> and then set all methods to Required. The TransactionManager state was STATUS_ACTIVE and autocommit was still set to true. I would have thought that autocommit would be set to false when the datasource is aquired inside the scope of a Container managed bean transaction. Otherwise, how would the LocalTx Manager explicitly rollback and/or commit against a datasource that has autocommit turned on?

          • 17. Re: Setting the AutoCommit JDBC property in 3.0.1RC1
            duslow

            You mentioned this in a previous post:


            The main difference in behavior I can think of right now is that in 3.0 you should get autocommit behavior outside an explicit transaction.


            I did two tests with a stateless session bean that just aquired a Sybase connection from the LocalTx datasource pool and then logged the state of the TransactionManager and whether autocommit was true or false on the datasource connection.

            With <transaction-type>Bean</transaction-type>, the TransactionManager state was STATUS_NO_TRANSACTION and autocommit was set to true on the datasource connection. This was the expected behaviour, and jibes with your statement.

            I then tried <transaction-type>Container</transaction-type> and then set all methods to Required. The TransactionManager state was STATUS_ACTIVE and autocommit was still set to true. I would have thought that autocommit would be set to false when the datasource is aquired inside the scope of a Container managed bean transaction. Otherwise, how would the LocalTx Manager explicitly rollback and/or commit against a datasource that has autocommit turned on?

            • 18. Re: Setting the AutoCommit JDBC property in 3.0.1RC1
              duslow

              You had mentioned this in a previous post:


              The main difference in behavior I can think of right now is that in 3.0 you should get autocommit behavior outside an explicit transaction.


              I did two tests with a stateless session bean that just aquired a Sybase connection from the LocalTx datasource pool and then logged the state of the TransactionManager and whether autocommit was true or false on the datasource connection.

              With <transaction-type>Bean</transaction-type>, the TransactionManager state was STATUS_NO_TRANSACTION and autocommit was set to true on the datasource connection. This was the expected behaviour, and jibes with your statement.

              I then tried <transaction-type>Container</transaction-type> and then set all methods to Required. The TransactionManager state was STATUS_ACTIVE and autocommit was still set to true. I would have thought that autocommit would be set to false when the datasource is aquired inside the scope of a Container managed bean transaction. Otherwise, how would the LocalTx Manager explicitly rollback and/or commit against a datasource that has autocommit turned on?

              • 19. Re: Setting the AutoCommit JDBC property in 3.0.1RC1
                duslow

                Test

                • 20. Re: Setting the AutoCommit JDBC property in 3.0.1RC1
                  duslow

                  My apologies for the duplicates. I was having an issue with posting to the forum earlier today and thought my posts were not getting thru because they weren't showing up after I had posted...if a sysadmin of the forum is able to remove them, please do.

                  • 21. Re: Setting the AutoCommit JDBC property in 3.0.1RC1
                    davidjencks

                    Sorry, I didn't explain what was going on clearly enough.

                    The autocommit setting (get/setAutoCommit) on the Connection handle is only usable and meaningful when you are outside a managed (jta) transaction. It is not directly connected to the underlying connection's autocommit setting.

                    Even though it may return "true" when you are in a jta tx, the tm is really in control, and you are really in a transaction. If you try to change the autocommit setting, it should throw an exception... I hope.

                    I suppose it might be even more appropriate to throw an exception if you are in a jta tx and ask about autocommit...

                    It's a little hard for me to know what the best behavior here is. Basically I think having an autocommit setting and then automatically started local tx is a really dumb model: the jca cci LocalTransaction makes a lot more sense, where you explicitly start and commit local tx using a local tx object. The jca spec says work done outside a jta tx and outside a LocalTx should be autocommitted, and I'm trying to emulate that with the autocommit behavior.

                    • 22. Re: Setting the AutoCommit JDBC property in 3.0.1RC1
                      duslow

                      The container does throw an exception when you attempt to setAutoCommit(true || false) when in a jta tx. I have not tried to do it in a bmt session bean yet and would assume that it would allow the alteration.

                      IMO, I think that if getAutoCommit() is not going to throw an exception when called in a jta tx, then it should mirror the state of the underlying driver. I realize that for cmt, one really doesn't need to probe the autocommit status and do any logic around that, however in bmt session beans, I do think coding logic against that status could be appropriate in some bmt designs.

                      I made another discovery today that there was code in one of the cmt stateless session beans that was closing the datasource connection first, then the result set, and finally the prepared statement. Although it worked in 2.4.4 (with the same jdbc driver), in 3.0.1, it caused the Sybase driver fits (or maybe the LocalTx) and the driver threw SQLException,"SET CHAINED command not allowed within multi-statement transaction." which farther up the stack trace turned into an IllegalStateException: "removing bean lock and it has tx set!."

                      I rearranged the code to close the prepared statement first, then the result set and the connection, and that cured the error.

                      So, I'm getting close to cleaning up the loose transactional ends in our code base. I have to say that I am very surprised at how loose 2.4.4 was in terms of what it would let you "get away" with. I'm just very relieved that there are not many instances of this code in the system, otherwise, the move to 3.x would probably not happen on this release cycle for us. Moving to 3.0.2 is probably a good idea as well since it seems a few tranasaction related bugs where fixed. Hopefully binaries of that will be released soon so that I don't have to bite the bullet and learn how to build jBoss (just yet anyway).

                      I also noticed that version 4 is already brewing and I'm a bit worried about having to make the leap once again from 3.x to 4.x. The configuration change from 2.4.4 to 3.0.1 was pretty substantial in places, so should I just wait for 4.x? The ink has barely dried on 3.x and you guys are already working on 4.x! :)

                      • 23. Re: Setting the AutoCommit JDBC property in 3.0.1RC1
                        duslow

                        Actually I did try the test of setAutoCommit(false) in a bmt stateless session bean and it did throw an exception. I don't have the stack trace here in front of me now, but the message was something like "you are not allowed to setAutoCommit() in a managed transaction". Sorry for the confusion and I realize that I've been slinging around alot of different scenarios in this thread.

                        • 24. Re: Setting the AutoCommit JDBC property in 3.0.1RC1
                          davidjencks

                          If you find that something that should work isn't working, can you please extend LocalWrapperCleanupUnitTestCase to demonstrate the problem and submit a patch to the sourceforge patch tracker?

                          Building jboss is really easy,

                          cvs .... co -rBranch_3_2 jboss-all

                          cd jboss-all/build
                          ./build.sh

                          #testsuite
                          cd ../testsuite
                          ./build.sh tests

                          I don't expect configuration changes to be as painful from 3.x to 4.

                          • 25. Re: Setting the AutoCommit JDBC property in 3.0.1RC1
                            duslow

                            I moved to verion 3.2.0RC1 and no longer have any issues with transactions. Not sure what changed between 3.0.1RC1 and 3.2.0RC1, but whatever it was, it made all the difference.

                            I will still run the test suite against Sybase and report back my findings at some point in the near future.

                            1 2 Previous Next