[Zope-DB] Re: DCOracle2 leaking Oracle sessions/connections?

[Matthew T. Kromer]

I'm going to prune out the parts of the conversation that aren't aimed 
at me.

Chris Withers wrote:

> Bo M. Maryniuck wrote:

[...]

>
>>
>> Zope: Just Oracle session still opened, even after ZOracleDA instance 
>> deletion.
>
>
> So, you leak Oracle sessions? Has anyone else experienced this?


There is a definate handle leak in the 1.3 and earlier versons of the C 
code.  The latest C code fixed this.  This MAY stop the session leak.  
Each query leaked a describe handle.

[...]

>>>> There is another bug: ZOracleDA crashes ZODB transactions due to some
>>>> methods missing. I had fixed it, but Matt didn't included it to the 
>>>> CVS
>>>> -- leak time etc. There is _p_oid missing in _p_jar and sortKeys() in
>>>> SP.py also.
>>>

The sortKeys method I'm aware of, although that's just a ZODB warning.  
The _p_oid missing doesn't sound good to me; _p_oid is set by the ZODB 
mechanisms, never by user code.  The fact that you're not having it set 
indicates you're trying to create a stored procedure on the fly or 
something.


>
>
>>> Do you have a patch I can have a look at?
>>
>>
>> Yes.
>
>
> Can you mail it to me off list?
>
>>> What problems do you experience because of these missing bits and 
>>> pieces?
>>
>>
>> sortKey(): Then just you will have terrible experience with Stored 
>> Procedures: it will blow up your stupid_log with a procedure-related 
>> messages, sometimes even about 50-100 records per second. Really too 
>> much.
>
>
> Hmmm, haven't seen that thankfully ;-)


Thats new with Zope 2.6's ZODB.  It wants to order commits in a 
deterministic way.

>> _p_oid: Then Transaction.py will crash with exception and you will 
>> have such things, when Zope just hangs for you, but requests are 
>> received. After some thread is killed, then Zope works OK.
>
>
> Nor that, again thankfully...


I dont know where this is coming from.  I'd need a traceback to see what 
the call chain was, and I'd need to know where the SP was coming from.

> I know other thing: dco2 from DCOracle2 loaded TWICE. This sucks.
>
> What do you mean by this? (pointers to lines in the code would be 
> handy :-)


yes, I've seen this... no good explanation as to why it happens. 

I think the various imports aren't absolute, and it mucks something up 
by importing dco2 twice, even though it shouldn't.

The module was tweaked to help it tolerate this condition, but the 
problem is that some singletons might mutate if they are re-allocated on 
reload.  I think I have all of those nailed down so that they won't be 
reallocated but I don't guarantee that from memory.

>
>> Yes, this is new one. This is I use it to close the connection for 
>> sure. Then Oracle session disappears immediately. Saying 
>> "_v_database_connection.db = None" is not enough.
>
>
> Odd... anyone (Matt? :-) got any ideas why you need to call db.close() 
> and cursor.close() rather than just letting the garbage collector take 
> its course for the oracle session to be released?


Nope, *something* is holding on to a connection, but I'm not sure what 
it is.

-- 
Matt Kromer
Zope Corporation  http://www.zope.com/