Repository navigation
Question - Global transaction management #83
Description
Global transaction management is essential to surpass Spring.
Are there any plans to develop or integrate features like this?
I'm new to Python but have a strong background in Java and NodeJS (especially NestJS). I’ve been exploring Python web frameworks that offer a modular system based on dependency injection (DI), and PyNest seems to be on the right track—it's readable, maintainable, and scalable.
One thing, which is crucial: not every early-stage startup builds their backend using microservices architecture (MSA). Monolithic architecture is much simpler and faster for building an MVP. In this context, global transaction control through annotation-driven mechanisms can eliminate redundant boilerplate code. - begin transaction, end transaction and rollback.
Additionally, it enhances the reusability of services across domains. While this may not be recommended in MSA, it remains useful in certain cases. It is not only beneficial for monolithic applications but also for MSA.
Thanks!
Activity
itay-dar-lmnd commentedon Dec 24, 2024
@sunjoong85 Hi! Thank you for the kind words.
Regard the Global transaction management, are we talking about transaction in the context of Databases? If so, then there are a few ORM packages that are highly recommended to use in order to achieve this behaviour. One of them is SQLALCHEMY, that can manage all the transactions to the database.
ItayTheDar commentedon Oct 5, 2026
Clarifying the current state for the annotation-driven case you described: PyNest does not currently provide a
@Transactionaldecorator or automatic transaction propagation across service calls. The ORM providers expose SQLAlchemy sessions; transactions are controlled by your application code. For a single transaction spanning multiple services, pass the same session to those operations and use SQLAlchemy'swith session.begin():(orasync with session.begin():for an async session), rather than letting each service create/commit its own session.On current
main, the synchronousOrmProvider.get_session()rolls back on an exception and closes the session, but callers still explicitly commit; the asyncget_session()closes the session and does not implement decorator-style transaction management. So the earlier SQLAlchemy suggestion is a workaround, not the Spring-style feature requested here. Leaving this open as a feature request; no delivery date is committed.