Datasource for JBoss Messaging

[timfox]

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

[starksm64]

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?

[timfox]

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.

[adrian.brock]

"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.

[adrian.brock]

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.

[adrian.brock]

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 :-)

[adrian.brock]

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.

[timfox]

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.

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.