On 8/10/07, Alexandre CONRAD <[EMAIL PROTECTED]> wrote:
>
> Okay Mike,
>
> about scoped_session(), I think I got it right this time. I was trying
> to get inspired from SAContext, how it's beeing wrapped around with
> Pylons. Since SAContext has not yet upgraded to SA 0.4, maybe I was just
> getting inspired from some different mechanism. Or SAContext it doing it
> wrong. SAContext says you have to call the clear() method on your
> session on each new request.
>
> """
> *Important:* Put this line at the beginning of your base controller's
> .__call__ method (myapp/lib/base.py)::
>
>      model.sac.session.clear()
>
> This erases any stray session data left from the previous request in
> this thread.  Otherwise you may get random errors or corrupt data.  Or
> "del model.sac.session_context.current" if you prefer.
> """
>
> It sounds to me that the session is global and needs to be cleared
> everytime. Which I think is wrong (or SessionContext works differently).
> I think a *new* session should be created and attached to every new
> request. The session is then deleted automaticly when the request ends,
> rather than shared from a global obect (the Pylons' "model") and cleared
> (which is not thread-safe as I now understand).

sac.session is not a global attribute, it's a property that returns
sac.session_context.current.  sac,session_context is a SessionContext,
which manages its .current property to provide a session local to the
current thread and application.  After "del
sac.session_context.current", SessionContext automatically creates a
new session at the next access; this is a feature of SessionContext.

sac.session.clear() resets the thread-local session in place,
discarding any remnants of its previous use.  Both statements do
effectively the same thing, but I'm told that "del
sac.session_context.current" is more computationally efficient.

In SQLAlchemy 0.4, SessionContext is superceded by scoped_session,
which has a different API.  Assuming 'Session =
scoped_session(sessionmaker(...))', 'Session()' is the equivalent to
'session_context.current'.  MikeB says the preferred way to reset a
session in 0.4 is 'session.close()'.  This does the same as
'session.clear()' but also releases any network connections or other
resources that are being held.

*If* SAContext replaces .session_context with .session_factory
(equivalent to 'Session' above), the .session property would be
redefined to return self.session_factory()'.  Then you'd put this in
your controller method:
    model.sac.session.close()
*after* the superclass call.  I'm thinking about adding convenience
methods sac.start_request() / sac.end_request() to avoid any
confusion, and also to isolate the controller from changes in the
session code.  But SAContext will not be upgraded until SQLAlchemy 0.4
beta comes out, because the SQLAlchemy API is changing too quickly for
me to keep up with.

If session.close() exists in SQLAlchemy 0.3, I didn't know about it.

-- 
Mike Orr <[EMAIL PROTECTED]>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to