How to avoid sending response before transaction saved in Grails?

Question

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?

Answer 1

This is probably due to caching, if you require guarantees as to state of db, you need to .save(flush:true).

Do note that this flushes all across your session, so it might affect performance in a negative way.

Edit: Not sure how I managed to read your question without seeing the part about you already doing flush:true.

Anyways, that is indeed the way you must go.

Answer 2

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.