Hello!

I have this idea for extending how the Hibernate query cache works, but I don't know nearly enough to tell if this is feasible or not:

Suppose I have a fixed SQL query Q, and I want to track the result set of Q as other users update the database (via Hibernate ). But, I don't want to keep hitting the database to track the changes to Q. I realized that Hibernate has all of the information necessary to do this in memory.

So, I was thinking of the following setup:

1) initial run of Q against the database. Results will get put in the query cache. Mark this query somehow so that it never gets evicted from the query cache

2) also mark all entities returned by the query, (which are in the second level cache), so they never get evicted

3) handle Hibernate PostUpdate event, and run in-memory equivalent of Q on updated entities

4) if update modifies the results of Q, then update results in query cache. This would simply entail adding or removing entity ids, since that is all that's stored in the query cache.

Any feedback on the feasibility of this plan would be greatly appreciated.

If I can get this working, then I can significantly reduce load on my database.

Background: server farm with memcached second level cache.