I've seen a couple of posts regarding this, but I can't understand why this has never been answered, apart from a fix that supposedly went into a 3.1 release.

I'm using 3.2.6-ga and am still experiencing the issue

I have a set that is defined and works in the second level cache. As soon as a filter is applied to the cache, it no longer gets hits in the second level cache. In my use case I can't use a where clause, as I'm filtering by status and may or may not need to apply different values. A Filter is the perfect solution, but not at the expense of disabling the L2Cache. The only way round I have at the moment is creating a collection for each status with it's own where clause. Yuck. I know other people have this problem, but is there any solution ?????

I don't understand why you can't use simple queries with where clauses (use positional parameters if your values change).
In such case you could benefit from activating and proper using the 2L-Query cache.

Hi pb00067, thanks for the reply, the reason I'm not using NamedQueries, is that I want to be able reference the same collections from two use cases. So for example I have a Department object where I want to list the associated employees (without having to write another service and DAO call, to put into the model) from within a CMS application I want all associated employees to that department, but from another request I just want to see employees with a certain status, which I can accomplish nicely with a filter applied. I see this as the exact use case for filters, unless I'm misunderstanding them. My question is why does the second level cache not work with collections that have filters applied ?

Because the 2L cache cannot know, if the cached collection is still valid or obsolete without executing the filter-query again.
You must consider that between a put into 2L cache and a later lookup into 2L cache, someone other in meantime could
have commited changes on associated entities in way that the filter would return another resultset as the cached.
As a serious 2Lcache implementation never has to return obsolete data, I assume that Hiberante simply deactivates
2L-cache on the collection if there is a filter applied.

With regard to stale data, theoretically what is the difference between a namedQuery that has bind parameters and is cacheable in the L2Cache, and collections with filters and bind parameters applied that is not cacheable ?

The L2Cache Query cache has a internal mechanism to detect if a cached result set is still valid or not.
It uses an appropriate UpdateTimestamp cache region for this purpose.
On queries hibernate can always establish which are the involved entity classes (called 'spaces' internally) to check for uptodateness. On filters I' am not sure if hibernate could do it also.

i've created a JIRA for it, as I don't see any theoretical difference between why namedqueries and non filtered collections are cacheable and filtered collections aren't. The issue is here: http://opensource.atlassian.com/project ... e/HHH-4888

Hi,
I can predict you that in this form your request on jira will be rejected.
1. What you want is definitely a request for improvement, not a bug.
2. Detailed description and testcase is missing.