Discussions
Categories
- 196.9K All Categories
- 2.2K Data
- 239 Big Data Appliance
- 1.9K Data Science
- 450.4K Databases
- 221.7K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 550 MySQL Community Space
- 478 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3K ORDS, SODA & JSON in the Database
- 546 SQLcl
- 4K SQL Developer Data Modeler
- 187.1K SQL & PL/SQL
- 21.3K SQL Developer
- 295.9K Development
- 17 Developer Projects
- 138 Programming Languages
- 292.6K Development Tools
- 107 DevOps
- 3.1K QA/Testing
- 646K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 155 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.1K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 18 Java Essentials
- 160 Java 8 Questions
- 86K Java Programming
- 80 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 204 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 442 LiveLabs
- 38 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 171 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 232 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.