Discussions
Categories
- 196.8K All Categories
- 2.2K Data
- 235 Big Data Appliance
- 1.9K Data Science
- 449.9K Databases
- 221.6K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 549 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 532 SQLcl
- 4K SQL Developer Data Modeler
- 186.9K SQL & PL/SQL
- 21.3K SQL Developer
- 295.5K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.2K Development Tools
- 104 DevOps
- 3.1K QA/Testing
- 645.9K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 154 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 17 Java Essentials
- 158 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 203 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 402 LiveLabs
- 37 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.6K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 230 Portuguese
setQueryTimeout() stopped working after upgrade from 10g to 11g

mpapesch
Member Posts: 12
Hi,
we are upgrading our database server from Oracle 10g to 11g and are experiencing a strange problem: the JDBC statement <tt>cancel()</tt> and <tt>setQueryTimeout()</tt> methods no longer work.
Starting out with the information given in [1,2], what we found out so far is that there seems to be a combination of a different behavior of the database and some kind of network issue.
While 10g accepted the <tt>cancel()</tt> request and promptly answered with the corresponding <tt>ORA-01013</tt> (user requested cancel of current operation), 11g seems to try and contact the client for a confirmation of the cancellation.
If the client is in the same subnet as the database server everything works as expected.
If, however, the client is in a different subnet, this request from the database server does not make it back to the client through the firewall.
Right now we are kind of stuck and any help, reference to documentation, workarounds and questions are greatly appreciated.
I'll be glad to gather and provide further information.
Thanks in advance,
Matthias
[1] http://stackoverflow.com/questions/2376615/how-is-oracles-jdbc-query-timeout-implemented
[2] http://blog.tanelpoder.com/2010/02/17/how-to-cancel-a-query-running-in-another-session/
we are upgrading our database server from Oracle 10g to 11g and are experiencing a strange problem: the JDBC statement <tt>cancel()</tt> and <tt>setQueryTimeout()</tt> methods no longer work.
Starting out with the information given in [1,2], what we found out so far is that there seems to be a combination of a different behavior of the database and some kind of network issue.
While 10g accepted the <tt>cancel()</tt> request and promptly answered with the corresponding <tt>ORA-01013</tt> (user requested cancel of current operation), 11g seems to try and contact the client for a confirmation of the cancellation.
If the client is in the same subnet as the database server everything works as expected.
If, however, the client is in a different subnet, this request from the database server does not make it back to the client through the firewall.
Right now we are kind of stuck and any help, reference to documentation, workarounds and questions are greatly appreciated.
I'll be glad to gather and provide further information.
Thanks in advance,
Matthias
[1] http://stackoverflow.com/questions/2376615/how-is-oracles-jdbc-query-timeout-implemented
[2] http://blog.tanelpoder.com/2010/02/17/how-to-cancel-a-query-running-in-another-session/
Answers
-
Hi! That is going to be enough of an Oracle-specific issue that you'll be more likely to get a quick answer with a service request to Oracle support. But you may get lucky and get an expert to answer here too...
-
Thank you for your quick response! We are considering this option now, while still hoping to get some further advice here ...
Regards,
Matthias -
I agree with Joe, an SR is going to be your best bet. This is almost certainly not a JDBC problem. Filling the SR against JDBC will probably slow down resolving the issue. Based on what you have written this probably is an issue (not necessarily a problem) with SQLNet.
Douglas
This discussion has been closed.