Re: [play-Java-2.2.x] One transaction, multiple requests

[Ryan Tanner]

It's a bad practice.  Best not to use transactions like this—keep them one per request.

If your business logic is such that whatever the user is creating isn't valid until it's done, keep it's state somewhere else (like another SQL table) and only commit it to its final location after the user has completed the process.  That way, each individual change can be its own transaction, with one single transaction at the end that creates the final record and clears the intermediate ones.

On Thursday, September 29, 2016 at 1:27:01 AM UTC-6, dsesp...@debmedia.com wrote:

Hello, I have the need to find a way to make a transaction live in multples http requests. I have a process which is triggered by a user on the front end, which involves a lot of creations and updates, my idea is to split them into multiple requests for the purpose of having a progress bar and inform the user who is performing this process. At the same time, I would like to make a big transaction for all these request  so if anything fault, make a roll back.

A first approach I came up with is to persist the transaction in RAM, the problem with this is that the server works in a high availability schema with multiple nodes and they don't share memory. Another idea is not create a large transaction and if something goes wrong make a roll back manually.

Another thing I wonder is if this idea I have is good or if it is a bad practice.

Any ideas ?

Thank you