Commons Dbcp
  1. Commons Dbcp
  2. DBCP-361

BasicManagedDataSource optional transaction enlistment

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Labels:
      None

      Description

      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)

        Activity

        Hide
        Aaron Hamid added a comment -

        I don't know why Spring does not detect the existing transaction (both the platform tx manager and bmds are injected with the same (JOTM) tx manager), but it appears that this means BMDS won't work with Spring declarative transactions and PROPAGATION_REQUIRED (which is the default).

        Show
        Aaron Hamid added a comment - I don't know why Spring does not detect the existing transaction (both the platform tx manager and bmds are injected with the same (JOTM) tx manager), but it appears that this means BMDS won't work with Spring declarative transactions and PROPAGATION_REQUIRED (which is the default).
        Hide
        Mark Thomas added a comment -

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

        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.

        Show
        Mark Thomas added a comment - I've spoken with Juergen Hoeller about the Spring aspect of this and his feedback was: 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.
        Hide
        Mark Thomas added a comment -

        Happy to re-open this if someone wants to provide a patch.

        Show
        Mark Thomas added a comment - Happy to re-open this if someone wants to provide a patch.

          People

          • Assignee:
            Unassigned
            Reporter:
            Aaron Hamid
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development