We’re running into transaction issue with Grails.
During performance test we have a scenario, where single API is called multiple times for the same user.
During each call something is changed on the domain object and it is saved in database.
We have discovered, that it is possible, that update in the database will be made after the response was sent to client and BEFORE another request for the same API arrives on the server.
So we end up with another API call which selects data from database before first API call updates it and we get StaleObjectStateException when second request tries to save stuff in database.
We were using the auto commit feature in Grails, which saves everything when transaction is finished. So the first decision was to start using .save() before render() in controller.
It’s ok when doing it for simple APIs, but we do have some more complex APIs where we would have to keep track of quite a lot objects and save them explicitly. Currently it seems to work without flush:true, but we are still testing.
So my question is: is there any way to make sure that response is not sent before transaction is committed in Grails?
This was due to a tool we used for testing – SoapUI. It can send a duplicate request before response comes back. This made us think it was a Grails fault. It was not.