Terracotta Discussion Forums

We implement ehcache as a fundamental part of our system,
because we manage some database tables with over 20,000 records.

Unfortunately, despite this, on many occasions ehcache
failure and can be viewed on the console a lot of hibernate queries on the tables that are supposedly cached.

We've done several tests to determine the exact cause of this problem, but behaves a random.

our ehcache.cfg.xml is something like it

<defaultCache
maxElementsInMemory="100"
eternal="false"
timeToIdleSeconds="120"
timeToLiveSeconds="120"
overflowToDisk="false" />

<cache name="mint.hibernate.bean.Employee"
maxElementsInMemory="30000"
eternal="true"
overflowToDisk="false"
>

The ehcache failt exactly when executes the folliwing code:

if(objectType == EResourceType.EMPLOYEE){

object = getSession().get(DBEmployee.class, objectKey.longValue());

if(employeeResourceLocationMap.containsKey(((DBEmployee)object).getKey())){

locationKey = employeeResourceLocationMap.get(((DBEmployee)object).getKey());
}else{
locationKey = ((DBEmployee)object).getLocationTree().getLocationKey();
}

if(object != null){

if(locationTimeZoneMap.containsKey(locationKey)){
timeZone = locationTimeZoneMap.get(locationKey);
}

else{

timeZoneObject = ((DBLocation)getSession().get(DBLocation.class, locationKey)).getTimezone();
timeZone = timeZoneObject;
if(timeZoneObject != null){
resourcesTimeZoneMap.put(objectKey,timeZoneObject);
}
locationTimeZoneMap.put(locationKey, timeZone);

}
}

}

What version of Hibernate/Ehcache and what console are you referring to?

we use ehcache version 1.6.0 and i refer to the output java conseole, there is a lot rows of hibernet queries.

we use hibernate 3 && ehcache 1.6.0

This issue is likely caused by a regression in the eviction algorithm introduced in 1.6 which has been fixed in 1.7.0-beta just released.

Up to 1.5 puts counted in the calculation of recent use. 1.6 only counted gets. So 1.6.0-1.6.2 evicted recently added items which had not yet been hit more than they should. This is why you were seeing more cache misses.

As to why it was behaving at random the evictor is probabilistic.

A fix has been applied in 1.7.0-beta.

Here is the test that reproduces the problem and demonstrates the fix:
http://ehcache.org/xref-test/net/sf/ehcache/store/LruMemoryStoreTest.html#138

Please upgrade to 1.7.0-beta and verify this fixes the issue.

thank you so much for this information
we really appreciate it

Hi,
We identify that the problem is present when the cache is used in a
concurrent context.

for example when we run our app and load the data and later whe run a test case with the following code:

while(true){

for(Long key : employeeKeys){
session.get(DBEmployee.class,key);
}

}

there is the hibernate queries in the console.

we 're using the following conf

<cache name="mint.hibernate.bean.DBEmployee"
maxElementsInMemory="30000"
eternal="true"
overflowToDisk="false">

</cache>

we appreciate your help.
thaks

Your expectation is that the "eternal" setting on the cache should mean that that infinite while-loop should never hit the database and always come from second level cache?

--Ari

yes,
we expect that ever the data is readed from the secound level cache.

When we run it alone, its run ok.....
but when run it at same time with our app it fail...

we have a similar problem with our app, sometimes we have a big amount
of hibernate queries in the java output console, we're trying to find the problem, maybe is a problem with concurrency.

thanks

Hi

Here's an example of test that reproduces the problem we've been having.

As they realize the problem can be seen most clearly when there are multiple sessions and threads running.

public static void testGetEmployeeWithThreads(){
EhCacheTestThread thread1 = new EhCacheTestThread();
thread1.setName("T1");
EhCacheTestThread thread2 = new EhCacheTestThread();
thread2.setName("T2");
EhCacheTestThread thread3 = new EhCacheTestThread();
thread3.setName("T3");
EhCacheTestThread thread4 = new EhCacheTestThread();
thread4.setName("T4");

System.out.println("Start t1");
thread1.start();
System.out.println("Start t2");
thread2.start();
System.out.println("Start t3");
thread3.start();
System.out.println("Start t4");
thread4.start();

}

I use the class EhCacheTestThread with the following method:

public void run() {

testGetEmployee();
}

/**
* Generic test with get employees.
* @author Juan Morales
*/
public void testGetEmployee(){
List<Long> employeeKeys = null;
Session session = null;

String sql = "select employee_key from employee";
employeeKeys = intHibernateUtil.getCurrentSession().createSQLQuery(sql)
.addScalar("employee_key", Hibernate.LONG)
.list();

while(true){
session = HibernateUtil.createSession();
try{
for(Long key : employeeKeys){
session.get(DBEmployee.class,key);

}

session.close();
sleep(1000);
}catch(Exception e){
session.close();
e.printStackTrace();

}

}

}

You can see the state of the threads with Jconsole and the hibernate queries
in the java output console

we appreciate if you can help us.
thanks beforehand.

juanux

The issue seems to be resolved.Please let know in case of more information.