Transactions between queue and database

Asked

Viewed 140 times

0

People like you handle transactions between queues and databases ?

I have a scenario where I must debit (Withdraw money from account) from a customer account and send a message in the queue, but if for some reason the message is not sent (Timeout or anything like that) I need to credit (Put money in account) the amount again in the customer account, I know I can simply do the credit in case of failure, but what if the failure to send to queue actually is an internet failure or something like that does not also make available the connection to the database making it impossible for me to undo the side effect ?

If I have already made the debit in the account and can not credit because there was a failure and my application is isolated from the world what I can do ?

Is there a different way to solve, instead of adding the queue submission method in the middle of my SQL transaction, to be able to do a Rollback if there is such a failure?

I am using Spring Boot 2, Java 8, Rabbitmq and SQL Server 2017.

  • has already used the @Transactional?

  • In the case of asynchronous communications such as queues, perhaps a good strategy is to use an Event sourcing

  • The only problem with @Transactional is that I don’t know if it has this transaction management of two separate objects (DB and Rabbitmq).

  • Event Sourcing is a great architecture, but I believe that just do not solve the problem.

1 answer

1


Ricardo Pontual is correct. The use of @Transactional can solve your problem. As the subject is very extensive and complex (and I have no experience with this use of transaction), I recommend reading two articles on this subject:

Now, since you don’t want to use transaction and are in a scenario where your application has become isolated from the world, you end up running out of options.

and if the failure to send to queue is actually an internet failure or something like that does not also make available the connection to the database making it impossible for me to undo the side effect ?

By default, Spring Boot will keep trying to send the message continuously until it can establish the connection with Rabbitmq and be able to send the message. This, in theory, would already solve your problem for you. Just be aware that I think there is a limit to trying this. but I believe that in Spring Boot this parameter is set to try without limit by default. See the documentation to be sure. Another problem here is that if during these new attempts the application is restarted, you will lose this message.

  • Thank you for your reply as soon as possible.

  • I decided to follow with the 1PC standard and check in every message if it had already been processed

Browser other questions tagged

You are not signed in. Login or sign up in order to post.