1 2 Previous Next 25 Replies Latest reply on Sep 9, 2002 1:46 PM by duslow

    Setting the AutoCommit JDBC property in 3.0.1RC1

    duslow

      Where does one set AutoCommit to false for a ManagedConnectionFactory in version 3.0.1RC1?

      I noticed in the CVS 1.12 version of the LocalManagedConnectionFactory.java file and I see new getter/setter methods for ConnectionProperties. I do not see these in the 1.1.2.10 CVS version (which has the tag 3_0_1).

      I cannot set autocommit to false programatically in the stateless session beans because I receive an error stating that I cannot set autocommit on a managed transaction resource.

      I scanned all the different *-services.xml examples I could find, but didn't see any example of setting autocommit.

      Don't know if makes any difference, but I'm using a Sybase database.

      Thanks,

      Dustin

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

          I take from the lack of response that either it isn't possible, no one knows the answer, or the question is a dumb one. I will assume the later and attempt to put the previous question into context of what I'm trying to accomplish.

          The behaviour I'm witnessing in stateless session beans and entity beans that are deploy with Bean managed transactions is that the LocalTx datasource that I setup is defaulting AutoCommit to true thus relinquishing my ability to manually commit and rollback the transactions when inside any ejb.

          On the jsp side of the application, I am able to set AutoCommit to false programatically and then commit or rollback the transaction with no problem at all.

          What am I missing where the EJB's are concerned? It appears from some of the stack traces that XA side of JBoss is in play here even though I have deployed the Bean with Bean managed transactions not Container and none of my database connections are using the XA driver.

          Can anyone provide some direction?

          Dustin

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

            Another possibility for the lack of response is that I am busy.

            I would expect the message about being in a managed tx to come from jboss only if you were in a managed tx, which might mean you didn't set up BeanManagedTx correctly. If you are certain you have set it up correctly and that there is no jta transaction in your session bean please let me know. I can't remember at the moment if there are tests for this in the testsuite. If the message comes from Sybase I would not put any bets on why.

            You should be able to use UserTransaction for your bmt. There are some tests of this in the testsuite.

            IMO it is not appropriate to have an autocommit setting in the managed connection factory properties. The jca spec requires cci adapters to autocommit work done outside an explicit transaction. I think this is a good idea even for non cci adapters. If you need to use jdbc local transaction control, I think it's reasonable to mark the beginning of your first tx by setting autocommit off.

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

              Thanks for the reply and I certainly didn't mean to impune your (or anyone else's) schedule or priorities.

              I am not able to setAutoCommit(false) using a connection from the new JCA based connection pools while requesting that connection from any ejb so your suggestion of doing that at the beginning of the transaction isn't currently possible with my current configuration (which may well indeed be configured wrong).

              The application worked fine in version 2.4.4 so I'm fairly certain all the deployment descriptors should be correct, although I will do an audit of these to make sure.

              In version 2.4.4 we were using the following setup and it works fine.


              org.hsqldb.jdbcDriver,com.sybase.jdbc2.jdbc.SybDriver



              PoolName
              org.jboss.pool.jdbc.xa.wrapper.XADataSourceImpl

              jdbc:sybase:Tds:my.server.url:2025/DatabaseName
              name
              10
              password
              true
              true
              0




              I am now using this:





              <depends optional-attribute-name="ManagedConnectionFactoryName">
              <!--embedded mbean-->


              DatabaseName



              <config-property name="ConnectionURL" type="java.lang.String">jdbc:sybase:Tds:my.database.url:2025/DatabaseName</config-property>
              <config-property name="DriverClass" type="java.lang.String">com.sybase.jdbc2.jdbc.SybDriver</config-property>
              <!--set these only if you want only default logins, not through JAAS-->
              <config-property name="UserName" type="java.lang.String">username</config-property>
              <config-property name="Password" type="java.lang.String">password</config-property>



              <!--Below here are advanced properties -->
              <!--hack-->
              <depends optional-attribute-name="OldRarDeployment">jboss.jca:service=RARDeployment,name=JBoss LocalTransaction JDBC Wrapper



              <depends optional-attribute-name="ManagedConnectionPool">
              <!--embedded mbean-->


              0
              10
              5000
              15
              <!--criteria indicates if Subject (from security domain) or app supplied
              parameters (such as from getConnection(user, pw)) are used to distinguish
              connections in the pool. Choices are
              ByContainerAndApplication (use both),
              ByContainer (use Subject),
              ByApplication (use app supplied params only),
              ByNothing (all connections are equivalent, usually if adapter supports
              reauthentication)-->
              ByContainer



              <depends optional-attribute-name="CachedConnectionManager">jboss.jca:service=CachedConnectionManager

              <depends optional-attribute-name="JaasSecurityManagerService">jboss.security:service=JaasSecurityManager

              java:/TransactionManager
              <!--make the rar deploy! hack till better deployment-->
              jboss.jca:service=RARDeployer



              Aside from the XA versus Local differences, what are the differences in transaction semantics from the old way, and the new JCA LocalTx way?

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

                Whoops .. I missed replacing NationalActMgt2 with DatabaseName in the example above, so ignore that typo.

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

                  2.4.4 didnt' really worry sufficiently about autocommit settings...I don't think they were reset for you if you returned a connection with autocommit true. Anything you got out of the pool had autocommit false.

                  In 3.0, the tx semantics should actually be the same, since in 2.4 the XADataSourceImpl performed roughly the same function as the Local tx wrapper. (except it had to resort to numerous hacks in order to work).

                  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. (tx boundaries either being cmt jta tx, UserTransaction, or setting autocommit false and calling commit/rollback on the connection).

                  The first thing I'd test is that there is no jta transaction. Look up the tm in jndi

                  TransactionManager tm = (TransactionManager)new InitialContext().lookup("java:/transactionManager");

                  log.info("tx status: " + tm.getStatus);

                  If the status shows there is no tx, then you found a bug in the jca wrapper and I hope you will turn your example into a test case or at least supply something that shows the problem. If there is a tx, your configuration of bmt is wrong.

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

                    I tried checking the status of the TransactionManager as you suggested and made an interesting discovery.

                    The scenario is a stateless session bean that calls an entity bean. The stateless session bean's transaction status is STATUS_NO_TRANSACTION, but the entity bean that it calls is STATUS_ACTIVE.

                    ejb-jar.xml: (names have been changed to protect the innocent)

                    <?xml version="1.0"?>

                    <ejb-jar>
                    <enterprise-beans>

                    <ejb-name>SessionBean</ejb-name>
                    com.foo.SessionBeanHome
                    com.foo.SessionBeanRemote
                    <ejb-class>com.SessionBean</ejb-class>
                    <session-type>Stateless</session-type>
                    <transaction-type>Bean</transaction-type>


                    <ejb-name>EntityBean</ejb-name>
                    com.foo.EntityBeanHome
                    com.foo.EntityBeanRemote
                    <ejb-class>com.foo.EntityBean</ejb-class>
                    <persistence-type>Bean</persistence-type>
                    false
                    <prim-key-class>java.lang.Integer</prim-key-class>

                    </enterprise-beans>
                    </ejb-jar>

                    jboss.xml:

                    <?xml version="1.0" encoding="UTF-8"?>

                    <enterprise-beans>

                    <ejb-name>SessionBean</ejb-name>
                    <jndi-name>SessionBean</jndi-name>


                    <ejb-name>EntityBean</ejb-name>
                    <jndi-name>EntityBean</jndi-name>
                    <configuration-name>Standard BMP EntityBean</configuration-name>


                    </enterprise-beans>


                    From what I understand, these configuration files should be ok, but for some reason the container transaction on the entity bean is being activated. I know this thread may now be a better topic for a different forum, but I at least wanted to finish this out just in case someone else goes down this path.

                    The error that occurs in the EntityBean is "java.lang.IllegalStateException: removing bean lock and it has tx set!". This error is what started me down the path of the autocommit being improperly set to true when I need it to be false in the BMP Entity bean.

                    If you have any suggestions in how to proceed, I am certainly interested in hearing them.

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

                      I'm less and less sure of what you are trying to do, but at least I now know why it doesn't work: entity beans are cmt only, and the default transaction attribute in jboss is Required...

                      I don't think trying to run around the "no bmt in entities" requirement is a good idea. If you really need to do some work in a separate transaction from inside an entity bean method, I'd advise putting the work in another (possibly session) bean and calling it.

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

                        I appreciate the information and I agree with you 100%. Had I authored this system that I have now been given the task to port from 2.4.4 to 3.x, I would have used container transactions everywhere. I have already been in talks with the developers about going away from bmt entirely in all of EJBs. I now have yet another good reason to share with them.

                        Having said that, I'll attempt to clarify the scenario. I do not need a separate transaction, and in fact I don't need a transaction at all. Basically the chain of events is that a jsp page calls a bmt stateless session bean that does some business logic and in turn calls a find_by (read only) method on an bmt entity bean. No data is modified in the entity. When the entity bean attempts to close the datasource connection after it has finished it's work, the IllegalState error occurs.

                        I'm not sure why closing the connection, even if cmt was on would cause the illegal state error. I was under the impression that even with cmt, you still have to explicitly close the datasource connection to release it back into the pool. I was going down the autocommit path simply because I observed in 2.4.4 that autocommit was set to false coming from the pool, whereas in 3.0.1, it was true regardless of whether the bean was bmt or cmt. I now realize that that was probably a red herring.

                        One side note though. I did try to manually set autocommit to false in a bmt stateless session bean and received an error that I was not allowed to set autocommit on the LocalTx datasource connection because it was apart of a managed transaction so is bmt not possible with LocalTx in any type of bean?

                        A session bean could be used in place of the entity bean, minus the performance gained by the entity bean cache, which was why the choice was made for an entity bean. I don't have a good "excuse" for why bmt was chosen as well being that I wasn't around for that decision. :)

                        Anyhow, I suppose it is really pointless to attempt figure out how to make it work as is and to just bite the bullet and get rid of bmt. Although, I think you elluded that bmt could be done in 3.x with entities if I explicitly define the methods in the entity's deployment descriptor that I don't want transactions for? I also tried the <read-only>True</read-only attribute, but it made no difference in how the container saw the bean, it still wanted to enlist it in the container transaction.

                        I am very grateful for your help. I'm a recent jBoss convert coming from 2.5 years of development in Weblogic and have enjoyed the ride thus far. It's people like you that should be commended for the time you take to not only code jBoss components, but to also take the time to help those of who just took the red pill or was it the blue pill? :)

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

                          I'm confused by the problems you are having. Many of the things you are trying to do are tested in the org.jboss.test.jca.test.LocalWrapperCleanupUnitTestCase. You might take a look at it and perhaps try running it with your driver setup.

                          In the particular situation you are in, I'd try to take advantage of commit option A, use cmt in your entity as required by the spec, and see if you can use cmp.

                          • 10. 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?

                            • 11. 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?

                              • 12. 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?

                                • 13. 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?

                                  • 14. 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?

                                    1 2 Previous Next