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

[Chris Withers]

Bo M. Maryniuck wrote:

> If you like answer quickly, just get it off-list. ;-) At the evening I will 
> try to setup my pop servers, etc (they'we changed).

(sorry, I'm CC'ing in the list so Matt can pile in and help, gopefully you'll be 
able to get around you rather odd office policy somehow ;-)

>>This isn't entirely unexpected. Cursor's keep their own connection, in
>>fact, with Oracle, I'd expect you to be able to have multiple cursors per
>>connection. How does the connection not closing cause you problems?
> 
> Zope: Just Oracle session still opened, even after ZOracleDA instance 
> deletion.

So, you leak Oracle sessions? Has anyone else experienced this?

>>What is db.close() supposed to do?
> 
> Code sais me to close main db connection instance, not cursor with theirs db 
> instances.

yup, what Matt has said backs that up...

>>What is cursor.close() supposed to do?
> 
> Probably close current cursor.

Sounds fair, have you experienced any problems here?

>>>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.
>>
>>Not sure what you mean by this. Do you have a URL to the collector issue?
> 
> No.

Okay, well, which collector was it in? ;-)
Matt, what're your views about this?

>>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 ;-)

> _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...

>>So, when the DA gets
>>deleted, the cursor and db still refer to each other. My question is why
>>python's cyclic garbage collector doesn't delete them?
> 
> Good question. Probably they are *instances*. 

Not sure of the point you're trying to make. Python's cyclic garbage collector 
handles instances as far as I know. What evidence do you have that it doesn't?

> 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 :-)

>>So, what was your code leaking before the above patch? DA instances? db
>>instance? cursor instances? can you definitely say that the above code
>>change means you no longer leak any of these three object types?
> 
> Yes. Sort of... Personally, I think ZOracleDA (Zope part, I mean) should be 
> refactored or even rewrited from the scratch. But I really have no time and 
> joy to do it.

Seems to be the view of a lot of people ;-)

> 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?

cheers,

Chris