OrmQueryRequest - skip cache put

[dragkes]

Hello. Currently, there are two methods in OrmQueryRequest that control whether a query should put to cache: isBeanCachePutMany and isBeanCachePut.
The issue is that isBeanCachePutMany uses transaction.isSkipCacheExplicit(), while isBeanCachePut uses transaction.isSkipCache(). The latter also checks whether the transaction is read-only. I believe both methods should use transaction.isSkipCache() as the current behavior can cause cache pollution when a batch insert is rolled back, because data may already be written to the cache

[rbygrave]

Noting that the logic around this was added with: #2016

current behavior can cause cache pollution when a batch insert is rolled back, because data may already be written to the cache

Yes, that is a good reason for changing this back to being more "conservative/safe" etc. Hmm.

[dragkes]

Yes. I’ve encountered this issue multiple times, and the "symptom" was the optimistic lock exceptions occurring when the SQL UPDATE was performed on stale data from the cache.
Additionally (not directly related to the our issue but still), I’ve noticed that the existing nested savepoint transaction logic can also cause cache pollution. If a nested savepoint transaction is committed, its changes are written to the cache immediately. However, if the outer main TX is later rolled back, those cache changes remain, even though the corresponding database changes were never finalized.
It would make sense to merge cache updates from nested transactions into the parent transaction’s cache changeset and only apply them when the main transaction commits.