• Bug
  • Status: Open
  • 2 Major
  • Resolution:
  • ehcache-core
  • Reporter:
  • March 18, 2010
  • 0
  • Watchers: 2
  • October 11, 2011

Description

Using “Hibernate 3.5.0-CR-2” and “EhCache 2.0” with “second_level_cache” and “query_cache”.

  • Deprecated method “SessionFactory.evictQueries()” => DOES NOT WORK

  • Considering “SessionFactory.evictQueries()” changed to “SessionFactoy.getCache().evictQueryRegions()” => ALSO DOES NOT WORK ReplyQuote

  1. Mar 2010, 20:31 CET | Link DdEviL Using “Hibernate 3.5.0-CR-2” and “EhCache 2.0” with “second_level_cache” and “query_cache”.

  • Deprecated method “SessionFactory.evictQueries()” => DOES NOT WORK

  • Considering “SessionFactory.evictQueries()” changed to “SessionFactoy.getCache().evictQueryRegions()” => ALSO DOES NOT WORK

NOTE: With Hibernate 3.3.2 “SessionFactory.evictQueries()” WORKED just fine.

See http://in.relation.to/Bloggers/Hibernate350CR2Release

Comments

gluck 2010-03-18

Another post from the same reporter:

Using “Hibernate 3.5.0-CR-2” and “EhCache 2.0” with “second_level_cache” and “query_cache”.

  • When enabling these caches with JOIN FETCH the SELECT N+1 issue appears. If I disable both caches the N+1 issue does not happen:

Primary Key is (SYSTEM_CODE, NCODE)

CREATE TABLE FW_STATUS_TRANSLATE ( SYSTEM_CODE VARCHAR2(3 BYTE) NOT NULL , NCODE VARCHAR2(20 BYTE) NOT NULL , NDESC VARCHAR2(255 BYTE) , ECODE VARCHAR2(10 BYTE) , EDESC VARCHAR2(255 BYTE) , ACCAO VARCHAR2(48 BYTE) , RESPONSAVEL VARCHAR2(48 BYTE) , ACCAORECURSO VARCHAR2(48 BYTE) , RESPONSAVELRECURSO VARCHAR2(48 BYTE) , EVENTSTATUS VARCHAR2(100 BYTE) DEFAULT NULL )

Primary Key is (SYSTEM_CODE)

CREATE TABLE PTC_SISTEMA_LEGACY ( SYSTEM_CODE VARCHAR2(3 BYTE) NOT NULL ENABLE, SYSTEM_DESC VARCHAR2(50 BYTE) )

NOTE: There is a foreign key from FW_STATUS_TRANSLATE.SYSTEM_CODE to PTC_SISTEMA_LEGACY.SYSTEM_CODE

<?xml version=”1.0”?> <!DOCTYPE hibernate-mapping PUBLIC “-//Hibernate/Hibernate Mapping DTD 3.0//EN” “http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd”>

<?xml version=”1.0”?> <!DOCTYPE hibernate-mapping PUBLIC “-//Hibernate/Hibernate Mapping DTD 3.0//EN” “http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd”>

hibernateSession.createQuery( “FROM FwStatusTranslate t1 “ + “LEFT JOIN FETCH t1.system_code “ + “ORDER BY TO_NUMBER( SUBSTR( t1.ecode, 2 ) )” );

Steve Harris 2010-03-18

Is there enough here to make a guess at what the problem is?

Chris Dennis 2010-03-19

From my reading of the comments on the linked hibernate blog it seems that the user sees the behavior in:

Ehcache 2.0.0 and Hibernate 3.5.0-CR-2 Ehcache 1.5.0 and Hibernate 3.5.0-CR-2 OSCache and Hibernate 3.5.0-CR-2

but he doesn’t see the problem in Hibernate 3.3.2 (from reading between the lines I think this was with Ehcache 2.0.0).

I also manually tested the cache clearing behavior of “SessionFactory.evictQueries()” and it seems to be working correctly as per my reading of the code.

“SessionFactory.getCache().evictDefaultQueryRegion()” also seems to work. Note also that the javadoc for the “evictQueryRegions()” method that the user refers to is incorrect. This method does not clear the default query cache, it only clears explicitly named query caches. This may be partially to blame for the users confusion. Its particularly bad that the javadoc for the now deprecated “evictQueries()” method claims that the “evictQueryRegions()” method is its replacement when this is not the case.

It seems to me therefore that if there is a bug here (although it may just be a change in behavior that the user does not expect), then it is a Hibernate bug.

Chris Dennis 2010-03-22

Geert, I don’t think this is an issue (I suspect it is a test bug)…

(This comment was a mistake - I commented on the wrong issue)

Unless I can get more information my previous comment still holds.

Chris Dennis 2010-03-25

Greg, I can see no evidence that this is an Ehcache bug (certainly not a new one considering this was reproduced with 1.5 as well). The fact that it also happens with OSCache implies to me that this is either a change in behavior or bug in 3.5 Hibernate. If you can contact the original reporter for this could you try and get more information - or direct him to the Hibernate JIRA, if not I would recommend closing this as “Not a Bug” or “Not Reproducible”

Fiona OShea 2010-09-01

Moving all unresolved “Fix Revision 2.2.1” to fix revision “unknown” as we are releasing Magnum first which is 2.3. Currently not sure which fix version these will actually be in, but they are targeted for Fremantle release

Fiona OShea 2011-02-22

MOving unresolved P2 jiras to Ulloa - to be reviewed by Chris, Fiona, Greg soon