[Zope-DB] Returning values from Oracle function/procedure withZSQLMethod

[M.-A. Lemburg]

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
>>> 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 at zope.org
>> http://mail.zope.org/mailman/listinfo/zope-db
> 
> 
> _______________________________________________
> Zope-DB mailing list
> Zope-DB at 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 ! ::::