You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a workaround in #1293 to use select + flushCache=true for queries like INSERT ... RETURNING ..., but it looks like this workaround doesn't behave the same way update does. If you look at DefaultSqlSession it marks session dirty only on update/delete/insert, but not on select meaning that query will not be rolled back.
Currently we have to use copy of DefaultSqlSession (and therefore copy of DefaultSqlSessionFactory) to mitigate this issue by marking session dirty on selects as well. Given that Postgres is quite popular database I assume many people might be affected by that.
The text was updated successfully, but these errors were encountered:
In case this might be useful to you: I reported no rolling back after SELECT here #2363 but the developers said that the situation would be handled at connection pool level. I haven't yet had time to validate.
There is a workaround in #1293 to use
select
+flushCache=true
for queries likeINSERT ... RETURNING ...
, but it looks like this workaround doesn't behave the same wayupdate
does. If you look atDefaultSqlSession
it marks session dirty only onupdate
/delete
/insert
, but not onselect
meaning that query will not be rolled back.Currently we have to use copy of
DefaultSqlSession
(and therefore copy ofDefaultSqlSessionFactory
) to mitigate this issue by marking session dirty on selects as well. Given that Postgres is quite popular database I assume many people might be affected by that.The text was updated successfully, but these errors were encountered: