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