Is it possible 1.4.0 will fix a ORA-1000 issue?

[mauropagano]

Hi,

Not sure if this isn't the suggested way to ask this sort of questions, but I couldn't find a less intrusive way (opening an issue sounded more aggressive)

I was wondering if the fix introduced by e20c574 removes the potential for ORA-1000, where the library doesn't close the cursor (on the next rountrip) even though it should.

Asking since the description of the fix is a big vague and I recently stumbled on a ORA-1000 that didn't make much sense (code properly closes all cursor via contextmanager, SessionPool in use)

Thanks,
Mauro

[anthony-tuininga]

It is unlikely that those changes will cause a cursor leak. Those changes were simply surrounding when statements were cached and how many of them were cached. You can find out easily enough, though, by disabling the statement cache (setting the attribute stmtcachesize to the value 0) and running your test again.

There is anonther more recent commit (which I will push up to GitHub shortly) which would leak a cursor if an exception happened during the processing of a database response. That one may be more relevant, especially if your test cases involve exceptions being thrown frequently!

[cjbj]

Anthony meant that the (future) commit resolves a problem with a cursor leak, not that the commit leaks cursors! So without the pending commit you might see something undesired.

When it lands, you could try with it. And/or test is there is a statement cache issue.

[anthony-tuininga]

Yes, the _adjust_statement_cache() call closes cursors -- but only if the number of cursors exceeds the statement cache size. The point was that it shouldn't have been called then. Cursors would not be leaked, however. The number of cursors cached, however, was inaccurate before the patch.

[mauropagano]

Thank you both for the quick reply!

Understood now, I was barking at the wrong tree.

My ORA-1000 mystery thickens then (I can't seem to be able to reproduce at will under load either, yet at least!)

[cjbj]

I haven't seen reports of ORA-1000 for a very long time. We had a few reports from users with what are now very old versions of our node-oracledb driver. I wrote a blog which may have some general tips also applicable to Python: https://blogs.oracle.com/opal/post/node-oracledb-avoiding-ora-01000-maximum-open-cursors-exceeded

[mauropagano]

Thanks for sharing the blog post!

To be honest I haven't seen an ORA-1000 in a while either and they are usually pretty easy to pinpoint when reproducible :-(

Thanks again for engaging quickly, I'll share what I find in case I finally manage to reproduce!