commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas (JIRA)" <>
Subject [jira] [Updated] (DBCP-361) BasicManagedDataSource optional transaction enlistment
Date Fri, 14 Feb 2014 15:34:19 GMT


Mark Thomas updated DBCP-361:

    Fix Version/s:     (was: 2.0)

I've spoken with Juergen Hoeller about the Spring aspect of this and his feedback was:

bq. Anyway, the issue itself looks rather odd. Spring's JtaTransactionManager just delegates
to UserTransaction.begin/commit/rollback, and checks that UserTransaction's status first,
so certainly wouldn't ignore any existing transactions there. I rather suspect that the reporter
had an additional transaction management strategy involved next to JtaTransactionManager,
e.g. a Spring DataSourceTransactionManager which does obtain and commit JDBC Connections independently.

I suggest that if this is still an issue that you follow up with Spring via the relevant forum.

I'm not against adding the requested feature but it isn't something I am likely to work on
myself. As always, patches welcome. Without a patch this issue will eventually get resolved

> BasicManagedDataSource optional transaction enlistment
> ------------------------------------------------------
>                 Key: DBCP-361
>                 URL:
>             Project: Commons Dbcp
>          Issue Type: New Feature
>            Reporter: Aaron Hamid
> It would be nice to not automatically enlist connections in a transaction.  I have found
automatic enlistment can be problematic when using another transaction API such as Spring's
declarative transactions (JtaTransactionManager).  It appears Spring may create a second,
wrapping transaction.  With Oracle this leads to: ORA-02089: COMMIT is not allowed in a subordinate
> E.g. see Bitronix setAutomaticEnlistingEnabled

This message was sent by Atlassian JIRA

View raw message