I have a contrived use case to understand second level cache behaviour.

I'm making a query on a table that has ~million rows ( "Select * from table Service") . I have enabled the second level cache (EHCache) for the class that maps to this table. Per the EHCache configuration I expect that after 1000 objects are read to memory, the rest are written to disk. Therefore, if a million rows are being read from the table, 1000 objects should be in memory and 999,000 should be written to disk. I don't find this happening and get an out of memory exception.

My expectation was that the second level cache will prevent "out of memory exceptions from occurring" - at least in this specific use case. Is my expectation wrong?

The code is as follows:

public void testHibLoadService() throws Exception {

Transaction tx = session.beginTransaction();
String queryString = "from Service";

Query query = session.createQuery(queryString);

//query.setMaxResults(1000);

List list = query.list();

Iterator iter = list.iterator();

int count = 0;

while (iter.hasNext()) {

count++;

Service serv = (Service) iter.next();

String patientid = serv.getPatientid();

//System.out.println(patientid);


}


tx.commit();

log.info("<<< testHibLoadService()");

}

The relevant section in EHCache.xml is as follows;

<cache name="com.mycompany.persistence.Service"
maxElementsInMemory="1000"
eternal="false"
timeToIdleSeconds="300"
timeToLiveSeconds="600"
overflowToDisk="true"
/>


The second level cache itself works when the the fetch size is small. For example if I set:

query.setMaxResults(10000);

I can see data being written to disk for 9000 objects i.e 1000 are in memory.

Thanks,
Neel

it is the first level cache that is not releasing memory

Yes - that's the conclusion I arrived at ...but wasn't sure. Thanks for confirming it, Gavin.

It would be nice for the first level cache to have the ability to write to disk - just like the second level cache....

Neel

1rst level should not write to disk, it would be a performance killer... in my opinion.

Now think about what would happen if you do the same in jdbc --> exactly the same.

You can use paging on your query... it's done for this.

I don't see why providing a configurable option - just as in the second level cache - to write to the disk would be a performance issue.

You would write to the disk only if the memory/object usage reaches high levels. This would be better than getting an OME :)

Neel

in my opinion, it's just my opinion, Hibernate doesn't have to care about "unsecure" user code.
Hibernate Session is a business unit cache, if this session start to cover or prevent all kind of exception (outOfMemory for example) it will be more difficult to configure and i think less performant.

Take a look at sources, you'll see that it's not as easy at you say.
But why don't you modify it and provide an update? if it's clean and performant, sure the team will accept it ;)

It just seemed odd to me that the second level cache provides some nice features to handle huge data - but we can't even get to use it because the first level cache breaks down.


In our case - for a warehouse application (anybody use Hibernate for a warehouse application? ) - this is a genuine problem because I have to retrieve a huge chunk of data pertaining to a single individual in order to do some processing on it before writing it back to the db. Even with straight JDBC there are the usual issues of running out of memory. But there are caches that one can use with JDBC that will write to disk if the result set is huge - I believe Borland has one such cache (JDatastore ? ). Some of the light weight Java databases also have such a facility - at least their documentation says so.

So - it would be nice if the first level cache could do that too.

Neel

second level is different than fist level cache, otherwise it would have the same name ;)))
second level cache provides such a feature because it handles large amount of data, it is "connected" to a lot of fisrt level cache (hibernate session).

It's not exactly what you are saying.