[Zope-DB] DCOracle2: close connection doesn't

[Chris Withers]

Hi there,

(Matt K - would be very interested in your take on all this...)

Bo M. Maryniuck wrote:

> I had this problem also. This is because of db.close() does 
> not actually closes the session. I mean, if you call 
> manage_close_connection(), it calls 
> _v_database_connection.db.close() but this 
> is not enough:
> 
> *bo at zope:(~) python
> Python 2.2 (#1, Mar 26 2002, 15:46:04) 
> [GCC 2.95.3 20010315 (SuSE)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> 
>>>>import DCOracle2 as dco
>>>>d = dco.connect('user/pwd at dbtest')
>>>>c = d.cursor()
>>>>c.execute('select sysdate from dual')
> 
> 1
> 
>>>>c.fetchall()
> [[OracleDate("2003-09-19 17:48:43")]]
>>>>d.close()
>>>>c.execute('select sysdate from dual')
> 1
>>>>c.fetchall()
> [[OracleDate("2003-09-19 17:49:01")]]
>>>>c.close()

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?

> Yes, after cursor.close() -- all foo bar. IOW, cursor should be closed also and it does not
> depend from db.close() somewhy though it probably should.

Hmmm, okay, lack of understanding on my part here.
What is db.close() supposed to do?
What is cursor.close() supposed to do?
What do they do in DCOracle2's case?

> 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?
Do you have a patch I can have a look at?
What problems do you experience because of these missing bits and pieces?

> And there is yet another bug: normally you should have connection instance per thread. IOW,
> having four instances, you should have four connections. But ZOracleDA's instances
> slowly grows up. Fix (not insluded also) -- change the __del__() in db.py to this:
> 
> -------------------8<-----------------------------
>     def __del__(self):
>         #print "Deleting DCoracle2 connection"
> 
>         # Really break the reference
>        if self.cursor:
>            self.cursor.close()
> 
>         if self.db:
>             self.db.close() 
> 
>         self.cursor = None      # Break reference
>         self.db = None
> -------------------8<-----------------------------

Right, I'm guessing this works because the cycle being set up is that the cursor 
will hold a reference to the db, the db holds a reference to the cursor (?) and 
the DA holds a reference to the the db. 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?

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?

> Since I need some very advanced features from ZOracleDA (connection-per-user, etc), 
> I need session handling and transactions works really good to suppress developing my
> own DA from the scratch, but use existing one. To REALLY close the session, I've 
> also changed DA.py (also does not included to the CVS version):
> 
> class Connection(DABase.Connection):
>     " "
> 
> ....
>     
>     def teardown(self):
>         """ """
>     
>         if self._v_database_connection.db:
>             self._v_database_connection.db.close()
>     
>         if self._v_database_connection.cursor:
>             self._v_database_connection.cursor.close()
>     
>         self._v_database_connection.db = None
>         self._v_database_connection.cursor = None

Is this a new method you've added?

cheers,

Chris