Assuming we have 2 services, A and B. Service A has a function doing the following:
- Validate the data
- Call a service B function, that makes changes to the database
- Do some more stuff
- Do changes to the database
Now, let's assume that one of the following, steps 3 or 4 failed. Since service B made changes in the database, those changes are still there.
Is there any way of rolling the database back in this case? I though about database transactions, but I couldn't find any way to do that in nest js, although it is supported by TypeOrm, it doesn't look natural to nest. If not, I am now "stuck" with the changes occured by service B, but without the changes should have happen by A.
Thanks a lot.
Here is how I solved it since I needed to use a pessimistic lock.
I feel it is the "Nest" way of doing things as you can simply ask
NestJS
to inject an instance of a TypeormConnection
and you're good to go.Simply place whatever other logic you need inside the
.transaction
block and you're good to go.NOTE: You MUST use the
entityManager
provided by the.transaction
method or else it will not work.Many solutions are available, they should all be based on SQL transaction management.
Personally I feel that the simplest way to achieve that is to use the same
EntityManager
instance when you execute code on your database. Then you can use something like:You can spawn a
QueryRunner
from anEntityManager
instance that will be wrapped in the same transaction in case you execute raw SQL outside ORM operations. You need also to spawnRepository
instances fromEntityManager
as well or they will execute code outside the main transaction.In this case, you have to use the same transaction manager for both database operations. Unfortunately, I do not have an example repository, but I have found a potential solution using Continuation Local Storage (CLS) in Node:
https://github.com/typeorm/typeorm/issues/1895
This applies to Express.js, but you can create an instance of TransactionManager (for example, in a nest middleware) and store it per each request context. You then will be able to re-use this transactional manager across your service method calls, provided they are annotated with the @Transaction decorator implementation in the link above.
If there are no errors in your function chain, the transaction manager will commit all the changes made. Otherwise, the manager will roll back any changes.
Hope this helps!