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 <[EMAIL PROTECTED]>:
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
flexibility.
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@zope.org
http://mail.zope.org/mailman/listinfo/zope-db
_______________________________________________
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db
--
Marc-Andre Lemburg
eGenix.com
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 ! ::::
_______________________________________________
Zope-DB mailing list
Zope-DB@zope.org
http://mail.zope.org/mailman/listinfo/zope-db
