-
1. Re: Datasource for JBoss Messaging
starksm64 Oct 15, 2005 10:04 PM (in response to 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? -
2. Re: Datasource for JBoss Messaging
timfox Oct 16, 2005 1:20 PM (in response to timfox)"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 Oct 18, 2005 10:12 AM (in response to timfox)"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 Oct 21, 2005 9:13 AM (in response to timfox)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 Oct 21, 2005 9:20 AM (in response to timfox)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 Oct 21, 2005 9:23 AM (in response to timfox)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
timfox Oct 21, 2005 9:48 AM (in response to 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.
"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.