JBoss Transaction Manager
  1. JBoss Transaction Manager
  2. JBTM-93

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

    Details

    • Type: Bug Bug
    • Status: Closed Closed (View Workflow)
    • Priority: Major Major
    • Resolution: Done
    • Affects Version/s: 4.2
    • Fix Version/s: 4.2.1
    • Component/s: JTA, JTS
    • Security Level: Public (Everyone can see)
    • Labels:
      None
    • Similar Issues:
      Show 10 results 

      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.

        Issue Links

          Activity

          Hide
          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
          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
          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
          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
          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
          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
          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
          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
          Kevin Conner
          added a comment -

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

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

            People

            • Assignee:
              Kevin Conner
              Reporter:
              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