When looking for a cached Query in 2L-cache,
QueryResultsRegionImpl(BaseRegion) does temporary suspend the current transaction.
QueryResultsRegionImpl(BaseRegion).suspendAndGet(Object, FlagAdapter, boolean) line: 205
In this way only committed queries from already closed transactions are considered to be hit.
Cached queries put by the current transaction are totally ignored!
This is in my opinion a bug, because it changes behavior and degrades the efficiency of the 2L QueryCache
in respect to other 2L-implementations (for example EHCache).
Furthermore there is no reason to ignore cached queries deriving from current transaction:
the up-to-date-ness is checked anyway by the StandardQueryCache.isUpToDate() call.
simply not suspend current transaction when looking for cached querys,
then queries put by the current transaction are automatically considered as candidates for a hit.
3.5.0.Beta3, SQLServerr2008, integration with JTA
I believe the code that you're refering was there from the JBoss Cache days where get operations acquired locks, so I suspect that the aim to suspend the transaction was so that locks acquired as a result of the get were not held during the transaction. So, the decision was taken to suspend the tx and execute the get. I believe we should be able to execute a get() without suspending a tx. I'm double checking this with the person who wrote the original code.
Fixed by removing transaction suspend calls on get() cos Infinispan does not acquire locks on get().
Bulk closing stale resolved issues