Actually, now that I think about it, this is probably wrong. I'm reverting

this change for now.

What I observed is that in a ZODB based app, the ZODB connection was closed
when I let the closer fall out of scope.  I see from examining the code, 
though, that this is a side effect of the environ that the closer hangs on
to getting deleted.  There is nothing here that pops the registry when the
closer is deleted.  You still have to call the closer for that to happen.

1 files changed, 4 insertions, 6 deletions

diff --git a/repoze/bfg/scripting.py b/repoze/bfg/scripting.py
index 5694a8006..5399b7d77 100644
--- a/repoze/bfg/scripting.py
+++ b/repoze/bfg/scripting.py
@@ -4,12 +4,10 @@ def get_root(app, environ=None):
     The ``root`` returned is the application root object.  The
     ``closer`` returned is a callable (accepting no arguments) that
     should be called when your scripting application is finished using
-    the root.  The closer also closes the db connection when its ``__del__``
-    method is called.  This means the connection can also be closed by 
-    explicitly deleting the closer using ``del`` or, more commonly,  letting 
-    it fall out of scope.  If ``environ`` is not None, it is used as the 
-    environment passed to the BFG application root factory.  An empty environ 
-    is constructed and passed to the root factory if ``environ`` is None."""
+    the root.  If ``environ`` is not None, it is used as the
+    environment passed to the BFG application root factory.  An empty
+    environ is constructed and passed to the root factory if
+    ``environ`` is None."""
     registry = app.registry
     threadlocals = {'registry':registry, 'request':None}
     app.threadlocal_manager.push(threadlocals)