[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zope-db
Subject:    Re: [Zope-DB] Re: ZOracleDA and Oracle sessions: bug?
From:       "Matthew T. Kromer" <matt () zope ! com>
Date:       2002-10-14 14:40:45
[Download RAW message or body]

Bo M. Maryniuck wrote:

>On Monday 14 October 2002 16:17, Iain Bassam wrote:
>  
>
>>If you need to kill the sessions in Oracle, query v$session for the sid and
>>serial#. Then issue alter system kill session '<sid>,<serial#>';
>>    
>>
>
>Ugghhh... This is ugly solution. Also if I have a pool of connections and I 
>want remove not my own connection, but lots of others and this is impossible.
>
>2Matt:
>  
>
>>I suspect there's a cycle getting created somewhere, where the actual
>>connection object isn't being released.  Short of an explicit close() on
>>the connection object, the connection is actually only closed when the
>>connection object (the DCOracle2.py layer one) releases the C connection
>>object.
>>    
>>
>
>Hmmm... Hmm... Hm... Yes, seems that Zope still keeps the C object somewhere, 
>but I can't find where exactly. I've even tried to:
>
>	getattr(parent, myConn).manage_close_connection()
>	getattr(parent, myConn)._v_database_connection.cursor._cursor.close()
>	del getattr(parent, myConn)._v_connected
>	del getattr(parent, myConn)._v_database_connection
>
>...and session is still present. What I have to do to release the C object?
>
>  
>

Well, the problem probably is in the ZOracleDA code.

If you look at the db.py file, in the DB class, there's a __del__ method 
which tries to break cycles.  If you add to that method before the 
assigment to None a self.db.close() call, it will force the connection 
closed, regardless of what ever else may be using it.  The next thing 
that tries to use the closed connection will get an error.

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




[prev in list] [next in list] [prev in thread] [next in thread]