From: Mike Bayer Date: Sun, 12 Aug 2007 20:43:21 +0000 (+0000) Subject: edits X-Git-Tag: rel_0_4beta2~20 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=970ecb31c56758eb73d5a1ee77e5ab7a780ef9eb;p=thirdparty%2Fsqlalchemy%2Fsqlalchemy.git edits --- diff --git a/doc/build/content/session.txt b/doc/build/content/session.txt index 17fa969a3e..b1f4bc369f 100644 --- a/doc/build/content/session.txt +++ b/doc/build/content/session.txt @@ -672,9 +672,9 @@ A (really, really) common question is when does the contextual session get creat Session.remove() <- web response <- -Above, we illustrate a *typical* organization of duties, where the "Web Framework" layer has some integration built-in to manage the span of ORM sessions. Upon the initial handling of an incoming web request, the framework passes control to a controller. The controller then calls `Session()` when it wishes to work with the ORM; this method establishes the contextual Session which will remain until its removed. Disparate parts of the controller code may all call `Session()` and will get the same session object. Then, when the controller has completed and the reponse is to be sent to the web server, the framework **closes out** the current contextual session, above using the `remove()` method which removes the session from the context altogether. +Above, we illustrate a *typical* organization of duties, where the "Web Framework" layer has some integration built-in to manage the span of ORM sessions. Upon the initial handling of an incoming web request, the framework passes control to a controller. The controller then calls `Session()` when it wishes to work with the ORM; this method establishes the contextual Session which will remain until it's removed. Disparate parts of the controller code may all call `Session()` and will get the same session object. Then, when the controller has completed and the reponse is to be sent to the web server, the framework **closes out** the current contextual session, above using the `remove()` method which removes the session from the context altogether. -As an alternative, the "finalization" step can also call `Session.close()`, which will leave the same session object in place, may be used. Which one is better ? For a web framework which runs from a fixed pool of threads, it doesn't matter much. For a framework which runs a **variable** number of threads, or which **creates and disposes** of a thread for each request, `remove()` is better, since it leaves no resources associated with the thread which might not exist. +As an alternative, the "finalization" step can also call `Session.close()`, which will leave the same session object in place. Which one is better ? For a web framework which runs from a fixed pool of threads, it doesn't matter much. For a framework which runs a **variable** number of threads, or which **creates and disposes** of a thread for each request, `remove()` is better, since it leaves no resources associated with the thread which might not exist. * Why close out the session at all ? Why not just leave it going so the next request doesn't have to do as many queries ?