Grails

Hibernate 2nd Level Cache Regression

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0.2, 2.0.3
  • Fix Version/s: None
  • Component/s: Persistence
  • Labels:
    None
  • Environment:
    OS: Windows 7 x64
  • Testcase included:
    yes

Description

This is about the entity cache. The query cache seems to get hit.

I wen't to configure and verify our second level entity caches today on a 2.0.2 app. Just your basic configuration nothing special (grails create-app Foobar). Default values for the DataSource.groovy configuration with some additional configuration for debugging.

DataSource.groovy
hibernate { 
    cache.use_second_level_cache = true 
    cache.use_query_cache = true 
    cache.region.factory_class = 'net.sf.ehcache.hibernate.EhCacheRegionFactory' 
    format_sql = true 
    use_sql_comments = true 
    generate_statistics = true 
}

Then I created a new domain class. Again nothing special and added a cache: 'read-write' mapping configuration to it. It has a single field that is a string and for fun it is unique. Hashcode and equals are implemented for correctness.

Foobar.groovy
package me.bendoerr.foobar 
class Foobar { 
    String cookie 
    
    static constraints = { cookie unique: true }	
    static mapping = { cache(usage: 'read-write') } 
    
    boolean equals(final o) { /* removed for brevity */ } 
    
    int hashCode() { /* removed for brevity*/ } 
}

I then took the same method I use in Grails 1.3.7 to verify caching and implemented it in this project. To my surprise it failed! I spent most of the day debugging and I just do no see the entity cache being hit. Here is the integration test that I shamelessly stole from a guy named Trevor Burnham here http://jira.grails.org/browse/GRAILS-4868. You can find my test application at https://github.com/bendoerr/grails-ehcache-entity-cache-issue. It has a branch named grails-1.3.7 that shows the same application and test passing against 1.3.7 configurations. Also of note and evidence that the second level cache is not being hit is the sql logging output. Here is the integration test I am using.

CacheTests.groovy
class CacheTests extends GroovyTestCase {     
    SessionFactory sessionFactory 
    Statistics statistics 
    
    void setUp() { 
        new Foobar(cookie: 'Yum').save(failOnError: true, flush: true) 
        CacheManager.instance.clearAll() 
    } 
    
    void testCacheHits() { 
        5.times { 
            Thread thread = Thread.start { 
                Foobar.withTransaction { 
                    Foobar.get(1) 
                } 
            } 
            while (thread.isAlive()) Thread.sleep(1) 
        } 
        statistics = sessionFactory.statistics 
        assertEquals 1, statistics.secondLevelCacheMissCount 
        assertEquals 4, statistics.secondLevelCacheHitCount 
    } 
}

This test fails with an assertion error that there were actually 5 cache misses. 

    expected:<1> but was:<5> 
    junit.framework.AssertionFailedError: expected:<1> but was:<5> 
            at junit.framework.Assert.fail(Assert.java:50) 
            at junit.framework.Assert.failNotEquals(Assert.java:287) 
            at junit.framework.Assert.assertEquals(Assert.java:67) 
            at junit.framework.Assert.assertEquals(Assert.java:134) 
            at junit.framework.Assert.assertEquals(Assert.java:140) 
            at me.bendoerr.foobar.CacheTests.testCacheHits(CacheTests.groovy:27)

Test App Included

The test app which demonstrates this issue can be found on Github, the master branch demonstrates the regression with 2.0.3 and the `grails-1.3.7` branch demonstrates the test working against that version of grails.

Activity

Hide
Permalink
Benjamin R. Doerr added a comment -

Not an issue. Setting my integration test to static transactional = false allowed the test to pass. I wonder what is different that would cause this?

Show
Benjamin R. Doerr added a comment - Not an issue. Setting my integration test to static transactional = false allowed the test to pass. I wonder what is different that would cause this?

People

  • Assignee:
    Unassigned
    Reporter:
    Benjamin R. Doerr
Vote (2)
Watch (2)

Dates

  • Created:
    Updated: