Re: [cx-oracle-users] Crash of OCIStmtRelease during cursor.close()

[<Gui...@su...>]

Ok, that seems kind of consistent with what I meant to try out.
After you told me not to call close() explicitly, I commented the line out, but just to make sure the destructor was in fact being called I used the C/Python function Py_CLEAR(cursor), which decrements the number of handles on the cursor AND sets it to NULL afterwards. 

But tell me this: when the cursor actually goes out of scope and its automatically closed, won't it be cursor_close() which will be called when cursor is destroyed? If not, what will?

I meant to test this today but couldn't so I will tomorrow. You'll be first to know the outcome.

Thank you very much,

Guillaume



-----Message d'origine-----
De : Anthony Tuininga [mailto:ant...@gm...] 
Envoyé : jeudi 4 novembre 2010 17:52
À : cx-...@li...
Objet : Re: [cx-oracle-users] Crash of OCIStmtRelease during cursor.close()

Hi,

The idea I had was to null out the cursor handle after being freed so
that a second attempt to free it would not take place when
cursor.close() was being called. I later discovered that this was in
fact already taking place but not in a consistent fashion. So I have
checked in changes to deal with this (revisions 342 and 343) but I
strongly suspect that they won't have any bearing on your situation.
Of course to avoid the situation entirely just don't call close(). :-)
So if you take this route and the problem goes away that is highly
suggestive of the source of the problem.

Hope that answers your questions.

Anthony

On Thu, Nov 4, 2010 at 8:15 AM,  <Gui...@su...> wrote:
> Hi,
>
> Antony, I'm still open to trying that patch you had in mind yesterday. I'm gonna make a few tests at the client's this afternoon.
> Care to share your idea?
> I'm also going to try not explicitly closing the cursor and letting it close itself when garbage collected, see what happens.
>
> Thanks,
> Guillaume
>
>
> -----Message d'origine-----
> De : Aouizerate, Guillaume
> Envoyé : mercredi 3 novembre 2010 18:11
> À : 'cx-...@li...'
> Objet : RE: [cx-oracle-users] Crash of OCIStmtRelease during cursor.close()
>
> Hi
>
> I completely agree with the uselessness of calling executemanyprepared instead of just execute. I might just change this.
>
> I also agree on trying not to call close() after all. I was sceptical at first because our processes are actually using cxOracle from C code using the C/Python API and I wasn't sure cursors ever got out of scope but I just tried it and there's no regression, no ORA-01000.
> I'd have to test this on a client's configuration though because our problem is the kind of sick ones that only clients are able to reproduce in production but not us :-)
> But if the cursor is closed automatically, I'm wondering if we won't still get the same error but in the cursor's destructor now.
>
> Also, yes I can build my own cxOracle. This is actually what we're already doing. So any change you might want to test, I can implement in our build. I'll just have to patch a client and have them do the tests before confirming (or not) that the solution works. But this could probably be done pretty quickly.
>
> Thanks again for taking the time.
>
> Guillaume
>
>
> PS:
> Also if you're wondering why we're using cxOracle from C code, we're actually using it in a normal way from Python in our product's screens (written in Python). But the processes that actually do complex things with the data are written in C. So needing cx_Oracle for the python part, we decided (a long long time ago) to also use it in C. Ex:
> PyObject* pycrs=PyObject_CallMethod(*conn,"cursor",NULL);
> PyObject_CallMethod(pycrs,"execute","O",Py_None);
> PyObject_CallMethod(pycrs,"close",NONE);
>
>
>
>
>
>
> -----Message d'origine-----
> De : Anthony Tuininga [mailto:ant...@gm...]
> Envoyé : mercredi 3 novembre 2010 17:14
> À : cx-...@li...
> Objet : Re: [cx-oracle-users] Crash of OCIStmtRelease during cursor.close()
>
> On Wed, Nov 3, 2010 at 9:27 AM,  <Gui...@su...> wrote:
>> Hi, first off, thanks for your answer.
>
> You're welcome.
>
>>> 1) The latest version of cx_Oracle is now 5.0.4 which may or may not
>>> have resolved this problem. I've never noticed it myself so wouldn't
>>> be able to say.
>>
>> The reason we decided to use cxOracle 4.4 is because someone working with us two years ago already ported our product to 4.4 in one of our dev branches. Since 4.4 supports Oracle 11 and being in need of a quick solution, we decided to use that version.

>> It might be worth looking into 5.0.4 but there will certainly be some regressions with our software, as with 4.4 at first, which could take time to solve with no assurance of seeing our original problem solved.
>
> Ok.
>
>>> 2) Not sure why you wouldn't simply call cursor.execute(stmt) over
>>> cursor.prepare() and cursor.executemanyprepared(). Those last two are
>>> only needed for specialized situations and your code doesn't appear to
>>> require special processing.
>>
>> We call prepare() and then executemanyprepared() because calling prepare() allows us to check that cursor.statementType is not OCI_STMT_SELECT and to throw an exception if it is.
>
> Just reacting to the code you were showing me. Realize that if you try
> to fetch from a non-statement you will get a "not a query" exception
> anyway so you could catch that. I also don't see any reason in the
> code you demonstrated for executemanyprepared(). If that isn't
> acceptable you can also retrieve cursor.description which will be None
> in the case of a non-query. You can also quite easily call execute()
> even after prepare(). The code behaves exactly as if you attempted to
> execute a statement multiple times. The prepare phase is skipped.
>
> All of these are just suggestions. Feel free to ignore any or all of them. :-)
>
>>> 3) There is no need to call cursor.close() so you can try leaving that
>>> out as well.
>>
>> Ok, but won't I get an "ORA-01000: maximum open cursors exceeded" error if I don't close it? Unless you're suggesting that we use the same cursor for the execution of all statements.
>
> Once the cursor goes out of scope, it will be closed automatically. So
> you won't get ORA-1000 errors unless you never allow the cursor to go
> out of scope for some reason -- probably not a good thing anyway. :-)
>
>> If this is what you mean, the thing is we have several hundred processes in our software that our actually much much more complicated than the loop I wrote in my first email, and more and more clients are getting this problem but never on the same processes. Changing all of them is not really an option as this would take weeks of development and extensive testing.
>
> Of course. I wouldn't suggest that as a permanent solution -- just a
> means of determining the source of the problem.
>
>> I'd much rather know why cursor_close() is crashing than stop using it.
>
> Naturally. So would I. :-) I almost never use cursor.close() and I
> think most other people don't use it either so if there is a problem
> with cursor.close() it doesn't show up often. After reviewing the code
> a little more carefully I think I may have come up with a possible
> cause, however. Are you able to build cx_Oracle yourself and would you
> be willing to attempt a particular patch and test it in your
> environment? The only other options are for me to build a binary and
> send it to you for testing or for you to provide me a test case that
> demonstrates the problem. I'd prefer the latter given a choice, of
> course.
>
>>> 4) Do you have multiple threads in your application that are accessing
>>> Oracle? Database change notification? Either of those require threaded
>>> = True as part of the constructor of the connection object.
>>
>> Yes, our application is indeed multithreaded but we are already opening a threaded=True connection.
>
> Good.
>
> Anthony
>
>
>
> ------------------------------------------------------------------------------
> The Next 800 Companies to Lead America's Growth: New Video Whitepaper
> David G. Thomson, author of the best-selling book "Blueprint to a
> Billion" shares his insights and actions to help propel your
> business during the next growth cycle. Listen Now!
> http://p.sf.net/sfu/SAP-dev2dev
> _______________________________________________
> cx-oracle-users mailing list
> cx-...@li...
> https://lists.sourceforge.net/lists/listinfo/cx-oracle-users
>

------------------------------------------------------------------------------
The Next 800 Companies to Lead America's Growth: New Video Whitepaper
David G. Thomson, author of the best-selling book "Blueprint to a 
Billion" shares his insights and actions to help propel your 
business during the next growth cycle. Listen Now!
http://p.sf.net/sfu/SAP-dev2dev
_______________________________________________
cx-oracle-users mailing list
cx-...@li...
https://lists.sourceforge.net/lists/listinfo/cx-oracle-users