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 sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.