> When you do our own connection management, are you able to avoid
> DCOracle2 leaking connections? In our Zope
> 2.6.1/DCOracle2-1.3b server, we accumulate sessions where
> Oracle is waiting for a response from Zope, but Zope
> apparently thinks it closed that connection and opened a new
> one. Manually closing and reopening the connection does not
> clean up the forgotten sessions, so I periodically (~monthly)
> restart the Zope server to clean up. Killing the Zope
> processes seems to finally signal Oracle (on a remote
> machine) that the client is no longer interested in those old
> open sessions.
> The smidge of testing I did with DCOracle2 from the command
> line left me with the impression that its connection closing
> function did not work. I could close a connection - and then
> still use it to talk to my database. I wasn't really sure
> enough of those tests to report this as a bug, but it is
> vaguely troubling.
I've only experienced such problems using the object that wraps DCO2 for
zope. I've seen related issues discussed in detail on this list over
the past year or two, and this was another motivation for us to bypass
zope's wrapper and write explicit code against DCO2 instead.
On the other hand, I haven't been bitten by anything like what you
described above, using connect() from the base DCO2 module. (Note - with
the default installation layout, this often leads to an import statement
like from Products.DCOracle2.DCOracle2.DCOracle2 !) I can't say it's
bulletproof for certain, since I haven't been bitten, thus I havent
tested the hell out of it, but if we were leaking connections I'd have
heard by now...
Zope-DB mailing list