Re: [cx-oracle-users] cx_oracle does not close TCP/IP connections on close(); relies on Python garbage collection

[Michael B. <mi...@zz...>]

On May 14, 2011, at 12:46 PM, Amaury Forgeot d'Arc wrote:

> Hi,
> 
> 2011/5/14 Michael Bayer <mi...@zz...>:
>> I'm assuming this is intentional behavior, as illustrated by the script below.
>> Wondering what the rationale is for delaying the close of a connection until the object is garbage collected
> 
> It's true that the .close() method only calls OCISessionEnd().
> OCIServerDetach() is only called by the destructor.
> 
> A former colleague already noticed this: after close(), the connection
> disappears from v$session,
> but is still present in v$process (or v$thread, I don't remember)
> Since a closed connection can't be reopened, does this makes sense to
> keep the connection alive?
> IMO close() should release all resources, especially on the database server...


Specifically the issue we're having running SQLAlchemy unit tests, particularly the ones that test pools and connection configuration thereby by definition circumventing the usual practice of using a single connection pool, leave a few connections piled up which are closed, but in some cases are still in memory (fixing that now to seek and destroy absolutely every connection).   What happens next is you start getting ORA-12519 errors - no more connection slots left in which to connect.   What is particularly insidious about ORA-12519 is that even if the connection is fully closed, Oracle doesn't release the memory for a *full minute longer*, since apparently no message is sent to the listener to "deallocate" on close - its based on some kind of ping/timeout mechanism.