[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4836?page=c...
]
Galder Zamarreno commented on HHH-4836:
---------------------------------------
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.
Infinispan: 2L QueryCache don't considers cached queries which
belong to current transaction
--------------------------------------------------------------------------------------------
Key: HHH-4836
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-4836
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.5.0.Beta-1, 3.5.0-Beta-2, 3.5.0-Beta-3
Environment: 3.5.0.Beta3, SQLServerr2008, integration with JTA
Reporter: Guenther Demetz
Assignee: Galder Zamarreno
Original Estimate: 2 hours
Remaining Estimate: 2 hours
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.
Proposed solution:
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.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira