Potentially don't wire them together? That is, isolate them in separate parts of the code.

I always found Flask-SQLAlchemy a strange approach because it ties opposite and somewhat orthogonal parts of the request lifecycle together. When requests-to-data-transactions is a 1-1 relationship it's a convenience, but once you step out of that I think it's better to do things by hand.

My main app has a simple layer structure of "request > business logic > data layer". All of the business logic functions start a SQLAlchemy transaction using a Python decorator that is ~10 lines of SQLAlchemy code.

Check out how things are wired with in this Pyramid cookie cutter.

https://github.com/Pylons/pyramid-cookiecutter-starter/blob/...

I think same approach should work well for flask - just tie the session to the request object on first access.

Side note: I think we met on IRC few years ago ;-)

There is a lot going on in that cookie cutter. The “transaction” library for transaction management, wired into Pyramid with pyramid_tm, wired into SQLAlchemy with zope.sqlalchemy. Works nicely for Pyramid, but I don’t know how that translates to Flask.

Think on it like a middleware that wraps a transaction. It's fine, till you start consuming other Io based services (elastic/solar/...) And you find that this blocks one connection per request..

Doesn't, I wanted to show how it can be wired to request.