7 Replies Latest reply on Apr 9, 2012 12:50 PM by krot-s

    set-tx-query-timeout does not work?


      Hello all,


      I can't make set-tx-query-timeout option work in JBoss 7.1.0. Maybe I misunderstand it, could anyone clarify that?

      As much as I have understood this options automatically sets sql statements timeouts based on time left, which is calculated based on transaction timeout limit. Say I have transaction limit 10 sec, it will set first sql statement timeout equal to 10 sec, so my transaction ends after that timeout and control is returned back to calling thread, right?

      Instead, I see that timeout occures, but query continues execution and hangs for minutes.


      In the log I have following text:

      13:06:04,826 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a858582:-10c369f9:4f82b075:6d in state  RUN
      13:06:04,828 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 2) ARJUNA012095: Abort of action id 0:ffff0a858582:-10c369f9:4f82b075:6d invoked while multiple threads active within it.
      13:06:04,829 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 2) ARJUNA012108: CheckedAction::check - atomic action 0:ffff0a858582:-10c369f9:4f82b075:6d aborting with 1 threads active!
      13:06:04,831 WARN  [com.arjuna.ats.arjuna] (Transaction Reaper Worker 2) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 2,5,main] successfully canceled TX 0:ffff0a858582:-10c369f9:4f82b075:6d

      It appears at the right time, but queries lasts much longed.


      Did I misunderstand the feature?

      p.s. I use oracle jdbc6 thin driver, version 11.2

      if I specify query-timeout for datasource equal to 10 sec it works as intended.


      Thank you in advance.

        • 1. Re: set-tx-query-timeout does not work?

          Yes, you misunderstood this feature.  When a transaction times out the transaction manager does not interrupt the thread associated with the transaction.  It only marks the transaction as aborted (as you see in the log) so that when the thread attempts to commit or rollback the transaction an exception will be thrown (since one can't commit or rollback an aborted transaction).


          To be clear, interrupting the thread turns out to be a bad idea in most cases.  A well behaved resource manager will eventually time out on its own (this is a completely separate timeout from the JTA timeout set by the transaction manager or application).  At worst, a resource manager would be confused and left in an inconsistent state.  Further, most JDBC drivers use blocking I/O and happily continue on with their work even if the thread has been interrupted.

          • 2. Re: set-tx-query-timeout does not work?

            Thank you for reply,


            So, what does set-tx-query-timeout mean? What does it affect?

            • 3. Re: set-tx-query-timeout does not work?

              Re-reading your comment I think I misunderstood what you were saying.  You properly understood what the set-tx-query-timeout feature is supposed to do in essence.  I thought you were expecting the transaction timeout to interrupt the thread, but you are actually wanting the query timeout to take care of this instead - which is reasonable.  It does appear that the set-tx-query-timeout is not doing its job.

              • 4. Re: set-tx-query-timeout does not work?

                Here is additional info that may be helpful:


                [standalone@localhost:9999 /] /subsystem=transactions:read-resource(recursive=true)


                    "outcome" => "success",

                    "result" => {

                        "default-timeout" => 300,

                        "enable-statistics" => false,

                        "enable-tsm-status" => false,

                       "jts" => false,

                        "node-identifier" => "1",

                        "object-store-path" => "tx-object-store",

                        "object-store-relative-to" => "jboss.server.data.dir",

                        "path" => "var",

                        "process-id-socket-max-ports" => 10,

                        "process-id-uuid" => true,

                        "recovery-listener" => false,

                        "relative-to" => "jboss.server.data.dir",

                        "socket-binding" => "txn-recovery-environment",

                        "status-socket-binding" => "txn-status-manager"




                [standalone@localhost:9999 /] /subsystem=datasources/data-source=eflPool/:read-resource(recursive=true)


                    "outcome" => "success",

                    "result" => {

                        "allocation-retry" => undefined,

                        "allocation-retry-wait-millis" => undefined,

                        "background-validation" => false,

                        "background-validation-millis" => 0L,

                        "blocking-timeout-wait-millis" => undefined,

                        "check-valid-connection-sql" => undefined,

                        "connection-properties" => undefined,

                        "connection-url" => "jdbc:oracle:thin:@xx.xx.xx.xx:xxxx:dev11g",

                        "datasource-class" => undefined,

                        "driver-class" => "oracle.jdbc.OracleDriver",

                        "driver-name" => "ojdbc6.jar",

                        "enabled" => true,

                        "exception-sorter-class-name" => undefined,

                        "exception-sorter-properties" => undefined,

                        "flush-strategy" => undefined,

                        "idle-timeout-minutes" => undefined,

                        "jndi-name" => "java:jboss/datasources/eflPool",

                        "jta" => false,

                        "max-pool-size" => 10,

                        "min-pool-size" => 4,

                        "new-connection-sql" => undefined,

                        "password" => "xxxxxx",

                        "pool-prefill" => undefined,

                        "pool-use-strict-min" => undefined,

                        "prepared-statements-cache-size" => 10L,

                        "query-timeout" => 300L,

                        "reauth-plugin-class-name" => undefined,

                        "reauth-plugin-properties" => undefined,

                        "security-domain" => undefined,

                        "set-tx-query-timeout" => true,

                        "share-prepared-statements" => true,

                        "spy" => "false",

                        "stale-connection-checker-class-name" => undefined,

                        "stale-connection-checker-properties" => undefined,

                        "track-statements" => "\"NOWARN\"",

                        "transaction-isolation" => undefined,

                        "url-delimiter" => undefined,

                        "url-selector-strategy-class-name" => undefined,

                        "use-ccm" => false,

                        "use-fast-fail" => "false",

                        "use-java-context" => "true",

                        "use-try-lock" => undefined,

                        "user-name" => "flatbed",

                        "valid-connection-checker-class-name" => undefined,

                        "valid-connection-checker-properties" => undefined,

                        "validate-on-match" => false,

                        "statistics" => {

                            "pool" => undefined,

                            "jdbc" => undefined





                Options that I'm not sure about are: "jta" for datasource and "jst" for transactions subsystem, they are both set to "false" now.

                • 5. Re: set-tx-query-timeout does not work?

                  I'm not exactly sure, but it seems to be a bug.


                  Let me show the facts.

                  All datasources and prepared statement are wrapped by JCA datasource (from ironjacamar project). Right before query execution there is a call to org.jboss.jca.adapters.jdbc.WrapperConnection#checkConfiguredQueryTimeout(..), it in turn checks boolean variable org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory#isTransactionQueryTimeout, and setter for it is never called.

                  As I understand it should be called from org.jboss.as.connector.subsystems.datasources.AS7DataSourceDeployer#setMcfProperties(..), but I didn't find it there.

                  Is that a bug or some kind of misunderstanding? Should I post an issue to JIRA?

                  • 6. Re: set-tx-query-timeout does not work?

                    It looks like a bug to me.  The code in org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService.AS7DataSourceDeployer#setMcfProperties never inspects org.jboss.jca.common.api.metadata.ds.TimeOut#isSetTxQueryTimeout.  Please open a JIRA.  Thanks.

                    • 7. Re: set-tx-query-timeout does not work?