Michel Pelletier <michel@digicool.com> wrote:

...

-----Original Message----- From: Stuart 'Zen' Bishop [mailto:zen@cs.rmit.edu.au] Sent: Wednesday, December 08, 1999 8:58 PM To: Michel Pelletier Cc: zope-dev@zope.org Subject: RE: [Zope] Zope woes continue - server going down regularly. (pos sible solution)

On Wed, 8 Dec 1999, Michel Pelletier wrote:

...

This is because the connection gets opened, but never closed. Zope 2.x is hardwired to have only 7 available database connections. We'll probably add a knob in 2.2 that lets you configure the number of db connections. In either case, the problem is not the hardwiring, the problem is that your code has a bug in it, because you do not free the resource you are consuming. Do an:

x.close()

at the end of your method and you won't run out of connections.

Erm.... shouldn't ZApplicationWrapper have a __del__ method to do this, just in case? It isn't in there...

I messed up, it's x._p_jar to get the connection, but I see your point. You wouldn't want to do this, because other objects other than the root object may be using it.

Who has access to the newly-created connection, beyond the ZApplicationWrapper object which is going to go out of scope and be destroyed?

...

Otherwise, you would really need

try: x = Zope.app() # ... stuff return "Hello World!" finally: x.close()

Yes this actually works best.

-Michel

I don't buy it: if Zope.app() constructs and returns an object, whose constructor has a side effect of opening a new ZODB connection, then that object OWNS that connection and should clean it up in its destructor. Using try..finally to handle a _hidden_ side effect is convoluted -- this is why refcounts were invented. Tres. -- ========================================================= Tres Seaver tseaver@palladion.com 713-523-6582 Palladion Software http://www.palladion.com