Hello, Looking at the SQLAlchemy cookie cutter <https://github.com/Pylons/pyramid-cookiecutter-alchemy>, a request gets its own transaction-backed db session, and on its way out a response commits that transaction and closes the session. There are activation <https://docs.pylonsproject.org/projects/pyramid_tm/en/latest/#adding-an-activation-hook> and veto <https://docs.pylonsproject.org/projects/pyramid_tm/en/latest/#adding-a-commit-veto-hook> hooks too.
I'm trying to understand the details behind the request/response ↔ db session/transaction interaction. During ordinary operation, everything should work just fine and all modifications to ORM objects during a view functions commit with the response. But what happens when a transaction fails, for example because of a CHECK constraint? How exactly are race conditions handled: suppose two requests to the same endpoint at the same time, both create the same resource, one of which fails (well, should!) to commit. When and how is that handled? Thank you for pointers and tips and hints in advance 🤓 Jens -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to pylons-discuss+unsubscr...@googlegroups.com. To post to this group, send email to pylons-discuss@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/pylons-discuss/2a39e5b2-d8fa-43be-891c-4b1cd48d465e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
