7 Replies Latest reply on Oct 21, 2005 9:48 AM by Tim Fox

    Datasource for JBoss Messaging

    Tim Fox Master

      In the most recent changes to jboss messaging, I want the database acess to be done via a non-managed datasource.

      I only want local transactions, and i don't want auto-commit=true.

      In other words I just want a really simple javax.sql.DataSource with pooling and nothing more

      I believe, that even with a JCA managed datasource with local transactions, it will always set auto-commit="true" ???

      I haven't been able to work out how to get a JBoss datasource to do what i want, so for now I've just knocked together a *very* basic datasource that does no pooling and gets a new connection every time. This is obviously a temporary measure.

      Can anyone suggest how I can use a Jboss datasource to get the desired effect?

      Cheers


        • 1. Re: Datasource for JBoss Messaging
          Scott Stark Master

          Its the spec required behavior:


          7.13.1.1 Auto Commit
          When a connection is in an auto-commit mode, an operation on the connection automatically commits after it has been executed. The auto-commit mode must be off if multiple interactions have to be grouped in a single transaction, either local or XA, and committed or rolled back as a unit. A resource adapter must manage the auto-commit mode as follows:
          - A transactional resource adapter, either at XATransaction or LocalTransaction level, must set the auto-commit mode to false within a transaction, either local or XA, on a connection participating in the transaction. This requirement holds for both container-managed and bean-managed transaction demarcation.
          - A transactional resource adapter must set the auto-commit mode to true, on connections that are used outside a transaction.


          Have you tried a no-tx-datasource or just setting the auto commit on the connections obtained?

          • 2. Re: Datasource for JBoss Messaging
            Tim Fox Master

             

            "scott.stark@jboss.org" wrote:
            Its the spec required behavior:


            7.13.1.1 Auto Commit
            When a connection is in an auto-commit mode, an operation on the connection automatically commits after it has been executed. The auto-commit mode must be off if multiple interactions have to be grouped in a single transaction, either local or XA, and committed or rolled back as a unit. A resource adapter must manage the auto-commit mode as follows:
            - A transactional resource adapter, either at XATransaction or LocalTransaction level, must set the auto-commit mode to false within a transaction, either local or XA, on a connection participating in the transaction. This requirement holds for both container-managed and bean-managed transaction demarcation.
            - A transactional resource adapter must set the auto-commit mode to true, on connections that are used outside a transaction.


            Have you tried a no-tx-datasource or just setting the auto commit on the connections obtained?


            I had a look at no-tx-datasource and it looks like it should do what we want. :)

            My only worry is that using a JCA datasource is a bit of overkill for our requirements, since we're really only using it for it's connection pooling.

            It's my understanding that we'd need to start CachedConnectionManager, LocalManagedConnectionFactory, JBossManagedConnectionPool, NoTXConnectionManager, WrapperDataSource (??) services, when all we really want is a DB connection pool.

            This is probably not a big deal when deploying inside JBoss AS, but for running standalone it would be nice to minimise the number of service dependencies we have.

            Perhaps we should consider something like apache DBCP?

            I'd be interested to hear people's comments on this.



            • 3. Re: Datasource for JBoss Messaging
              Adrian Brock Master

               

              "timfox" wrote:
              when all we really want is a DB connection pool.

              This is probably not a big deal when deploying inside JBoss AS, but for running standalone it would be nice to minimise the number of service dependencies we have.

              Perhaps we should consider something like apache DBCP?

              I'd be interested to hear people's comments on this.



              By the sounds of it, what you really want to do is your own caching of connections?

              No connection pool is going to understand the context without a transaction.

              All no-tx-datasource gives you is the ability to not do automatic enlistment in the JTA
              transaction (big deal) which comes at the expense at getting a new connection on
              every DataSource.getConnection() coupled with very(overly?) fine grained jdbc (local) transactions.

              • 4. Re: Datasource for JBoss Messaging
                Adrian Brock Master

                From cvs commit


                2. jdbc connection pooling now done by apache dbcp


                There is little point me taking part in any of these discussions if you are just going
                to ignore me.

                FYI: http://jira.jboss.com/jira/browse/JBAS-1796

                This kind of stuff is just unacceptable.

                • 5. Re: Datasource for JBoss Messaging
                  Adrian Brock Master

                  To re-iterate.

                  1) You need a unit of work. JTA is a good unit of work.
                  It does virtually nothing unless you initiate 2PC (something you are not doing now, but will do when you want to "move" messages during bridging/routing).

                  2) You need a policy to cache the local jdbc transaction inside the unit of work.
                  Again JCA/local-tx-datasource does this for you.
                  Another way would be an hibernate session.

                  3) You need an abstraction to plugin connection pooling and caching.
                  Again a JCA connection manager is the way to go.

                  Let's stop this not invented here rubbish. Why re-invent something?
                  * There is already something that works, rather than your version which is almost certainly bug ridden!
                  * It is already supported
                  * It makes integration an order of magnitude more difficult (or more likely it follows an exponential pattern :-)

                  • 6. Re: Datasource for JBoss Messaging
                    Adrian Brock Master

                    And to avoid the repeat question.
                    The use of a JTA transaction to control the persistence is not the same thing
                    as the JMS local transaction branch.

                    • 7. Re: Datasource for JBoss Messaging
                      Tim Fox Master

                      Apologies - I added dbcp as a temporary measure so the server can run without dying during perf tests until we settle on the proper solution.

                      "adrian@jboss.org" wrote:
                      To re-iterate.

                      1) You need a unit of work. JTA is a good unit of work.
                      It does virtually nothing unless you initiate 2PC (something you are not doing now, but will do when you want to "move" messages during bridging/routing).


                      Actually, this is a good point I hadn't considered.

                      It should be a simple matter for me to change it to use JTA to control the jdbc local tx.