Bug #4122
closedsql:execute leaves open cursors in Oracle
100%
Description
A first xslt of our application generates an xml file with sql statements. A second xslt applies these statements to the database. But using a single sql:connection to execute a large number of statements using Oracle's JDBC driver (more than the server's OPEN_CURSORS limit) results in this error:
Error in sql:execute/@connection on line 30 column 62 of execute.xslt: (SQL) ORA-01000: maximum open cursors exceeded
In template rule with match="statement" on line 27 of execute.xslt Focus Context item: /statements/statement[301] Context position: 301 Local parameters $connection = oracle.jdbc.driver.T4CConnection@3b0fe47a Local variables $connection = oracle.jdbc.driver.T4CConnection@3b0fe47a invoked by xsl:apply-templates at file:/D:/Data/MyProjects/upp/upm-publish-processing/src/test/sql-execute/xsl/execute.xslt#18 In template rule with match="statements" on line 15 of execute.xslt Focus Context item: /statements Context position: 1 Local variables $connection = oracle.jdbc.driver.T4CConnection@3b0fe47a invoked by built-in template rule (text-only) (SQL) ORA-01000: maximum open cursors exceeded
We uploaded a small test case and use saxon-sql and saxon-ee both version 9.9.1.1. We solved this by patching the SQLExecute class and adding s.close(); after s.execute(statementText); but we have to do this with every new release, so we wondered whether this correction could not be definitively included in your code.
Files
Updated by Michael Kay almost 6 years ago
- Status changed from New to Resolved
- Applies to branch trunk added
- Fix Committed on Branch 9.9, trunk added
Thanks for reporting it. I have added the s.close() call in SQLExecute and SQLExecuteFn, as suggested. I'm afraid we don't do any high-volume or cross-database testing on the SQL module (originally it was all user-supplied code) so we rely on users to tell us about things like this.
Updated by Johan Gheys almost 6 years ago
Thanks for the quick response. That is greatly appreciated.
Updated by O'Neil Delpratt over 5 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in Maintenance Release 9.9.1.2 added
Bug issue fixed in the Saxon 9.9.1.2 maintenance release.
Please register to edit this issue