Uploaded image for project: 'JBoss Transaction Manager'
  1. JBoss Transaction Manager
  2. JBTM-93

Oracle setTransactionTimeout only propagates to server during XAResource.start method invocation

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Done
    • Affects Version/s: 4.2
    • Fix Version/s: 4.2.1
    • Component/s: JTA, JTS
    • Labels:
      None

      Description

      Invocations of the XAResource.setTransactionTimeout method are cached by the Oracle driver until a call to the XAResource.start method has occurred.

      The Type 4 driver accepts the new value and stores it locally but this does not appear to be propagated except as part of the start method invocation.

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            marklittle Mark Little added a comment -

            The document shows that it is configurable within WL and shows the reason why (which is what I had previously discussed). There is no one "correct location" to enforce this policy. It is often easier for sys admins to manage this within the TM configuration, particularly in a distributed environment where different interposed coordinators can have different runtime configuration options such as this. Furthermore, not everyone has the ability or the capability to add new XAResource implementations and ensure they are picked up (and driven correctly) by the application server. This does not have to be a global setting: it's configured on a per instance basis - different runtimes can see different values, which comes back to what I said before in the context of interposition.

            We can debate this for ages, but I want a configurable option for this. I believe there are good reasons for it and you have yet to prove that the absence of a configurable option is superior to its presence. Yet another benefit is the fact that customers migrating from WL may be using this option within their applications and expect it to be honoured.

            I find it ironic that you used the argument "WL does it this way so we should too so it must be right" for the calling pattern, and yet don't accept the same argument back

            Show
            marklittle Mark Little added a comment - The document shows that it is configurable within WL and shows the reason why (which is what I had previously discussed). There is no one "correct location" to enforce this policy. It is often easier for sys admins to manage this within the TM configuration, particularly in a distributed environment where different interposed coordinators can have different runtime configuration options such as this. Furthermore, not everyone has the ability or the capability to add new XAResource implementations and ensure they are picked up (and driven correctly) by the application server. This does not have to be a global setting: it's configured on a per instance basis - different runtimes can see different values, which comes back to what I said before in the context of interposition. We can debate this for ages, but I want a configurable option for this. I believe there are good reasons for it and you have yet to prove that the absence of a configurable option is superior to its presence. Yet another benefit is the fact that customers migrating from WL may be using this option within their applications and expect it to be honoured. I find it ironic that you used the argument "WL does it this way so we should too so it must be right" for the calling pattern, and yet don't accept the same argument back
            Hide
            kconner Kevin Conner added a comment -

            Actually, my argument for the calling pattern was "WL always makes the calls in this order so we know that they believe it works with all databases they support".

            If I remember correctly you rejected this argument yet now you employ it .

            If the intention is to support customers migrating from WL then I assume we will also have this disabled by default?

            Show
            kconner Kevin Conner added a comment - Actually, my argument for the calling pattern was "WL always makes the calls in this order so we know that they believe it works with all databases they support". If I remember correctly you rejected this argument yet now you employ it . If the intention is to support customers migrating from WL then I assume we will also have this disabled by default?
            Hide
            marklittle Mark Little added a comment -

            Add the configurable attribute. I'm not that bothered what the default is, as long as it's documented. You make that choice.

            Show
            marklittle Mark Little added a comment - Add the configurable attribute. I'm not that bothered what the default is, as long as it's documented. You make that choice.
            Hide
            kconner Kevin Conner added a comment -

            The order of the method invocations has been swapped and the setTransactionTimeout is now configurable.

            There are two ways to configure this functionality

            • specify the com.arjuna.ats.jta.xaTransactionTimeoutEnabled property (defaults to true)
            • programmatically using the setXATransactionTimeoutEnabled method on com.arjuna.ats.jta.common.Configuration
              (Boolean.TRUE/enabled, Boolean.FALSE/disabled, null/use property value)
            Show
            kconner Kevin Conner added a comment - The order of the method invocations has been swapped and the setTransactionTimeout is now configurable. There are two ways to configure this functionality specify the com.arjuna.ats.jta.xaTransactionTimeoutEnabled property (defaults to true) programmatically using the setXATransactionTimeoutEnabled method on com.arjuna.ats.jta.common.Configuration (Boolean.TRUE/enabled, Boolean.FALSE/disabled, null/use property value)
            Hide
            kconner Kevin Conner added a comment -

            Finer grained control of this functionality will be added in a later release

            Show
            kconner Kevin Conner added a comment - Finer grained control of this functionality will be added in a later release

              People

              • Assignee:
                kconner Kevin Conner
                Reporter:
                kconner Kevin Conner
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 day
                  1d

                    Development