[Zope-DB] Returning values from Oracle
mal at egenix.com
Wed Apr 13 11:49:34 EDT 2005
Matthew T. Kromer wrote:
> Chris Withers's branch of DCOracle2 has some changes that help the
> connection pooling problem.
> The issue basically is that the Zope adapter for DCOracle2 is fairly old
> and crusty. I think Jim's correct when he suggests doing your own pool
> management from a module.
> All that the DA is supposed to give you is a pool of connection objects
> and Zope transaction manager awareness. There's a little more to it
> than that, but the Zope DA is so old -- it derives from a product that
> predates Zope 2. It would probably be solved best by *jettisoning*
> Zope.Shared.RDBMS code, but...
> I don't actively maintain the code base any more (I haven't for about 18
> months). It isn't totally abandoned, but I don't work with Oracle at
> work any more, and so I don't have much of an itch to scratch to fix
> problems. My home installs of Oracle have all gotten clobbered by
> entropy (read: re-installs of Linux to counter failed hardware).
> You can also consider using eGenix's mxODBC adapter.
If you're on Windows, that's definitely worth a try.
On Unix you'll need an ODBC driver for Oracle, e.g. the
EasySoft one, since Oracle doesn't ship a driver with the
database (even though they do on Windows and it would probably
be easy for them to port it to Unix as well).
> On Apr 8, 2005, at 6:58 PM, Cynthia Kiser wrote:
>> Quoting Jim Abramson <jabramson at wgen.net>:
>>> In our experience we ended up needing to do increasingly complex
>>> things with plsql, and ultimately, we had no choice to move all our
>>> db access out into ExternalMethods or Products and use DCOracle2
>>> directly. This does require constructing your own connection
>>> pool/management, but once you've built that you can leverage
>>> DCOracle2 directly in python and this provides much more
>> 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.
>> Cynthia Kiser
>> Zope-DB mailing list
>> Zope-DB at zope.org
> Zope-DB mailing list
> Zope-DB at zope.org
Professional Python Services directly from the Source (#1, Apr 13 2005)
>>> Python/Zope Consulting and Support ... http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
More information about the Zope-DB