In most implementations, the answer would be: "None of the above".
Many MVC style frameworks (including all the near variants) will place the
SqlAlchemy session management in a WSGI middleware layer or a "tween".
Usually it will look like (pseudocode):
try:
sqlalchemy_session_setup(request)
handle_request(request)
finally:
sqlalchemy_session_cleanup(request)
The Transaction and Session are bound to the lifecycle of the request, and
often implemented with a two-phase commit to ensure other application
components commit.
It is incredibly non-standard to have more than one transaction within a
given request. It is also relatively non-standard to explicitly manage
transactions in the application code.
I do both of those (the former in very few circumstances) but am in a tiny
minority of users.
Dealing with multiple sessions (aside from separate read/write connections)
is very rare.
If you decide to handle session state yourself, you will need to address
the intricacies of lazy-loading and collections. If a collection/attribute
is not eager loaded, accessing it in a template will trigger a database
query. If you have already closed the connection or session, sqlalchemy
will reconnect and reload.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
