[
https://issues.apache.org/jira/browse/DBCP-361?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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 as WONTFIX.
> BasicManagedDataSource optional transaction enlistment
> ------------------------------------------------------
>
> Key: DBCP-361
> URL: https://issues.apache.org/jira/browse/DBCP-361
> 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 session.
> E.g. see Bitronix setAutomaticEnlistingEnabled
> http://btm.codehaus.org/api/1.3.3/bitronix/tm/resource/common/ResourceBean.html#setAutomaticEnlistingEnabled(boolean)
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
