Re: [jbosscache-dev] REPEATABLE_READ in JBC as Hibernate 2nd Level Cache
Manik Surtani wrote:
On 18 Jul 2008, at 16:35, Brian Stansberry wrote:
> Galder Zamarreno wrote:
>> Paul Ferraro wrote:
>>> refresh() always goes to the db, and only potentially triggers a 2LC
>>> update - not a read.
>>>
>
> [OT] A concern I have is whether the refresh() removes the item from
> the 2LC before doing the subsequent Hibernate cache put(). If not our
> putForExternalRead() usage will prevent the new value being placed in
> the cache.
Either way this should be tested. In the cache-jbosscache2 module in
hibernate-core, probably.
Haha! A bit of a kick in the pants. ;)
Done. And not a problem, refresh() works as expected. :) Test is in
org.hibernate.test.cache.jbc2.functional.PessimisticSessionRefreshTest
(optimistic and R_R flavor as well.)
BTW for anyone working on this testsuite, this test works by borrowing
the infrastructure that sets up two SessionFactories (normally used for
replicated tests). I add a simple config tweak that causes the second
factory not to use a 2nd level cache. I can then use that factory to
update the db w/o affecting the cache -- simulating an external process
that changes the db w/o hibernate knowing it. If you have a need for
another similar test, this approach is very simple.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com