Our web application uses Hibernate 3.1.3 with Ehcache 1.2 as a second level cache.

We are seeing a problem when multiple parallel requests query Hibernate for the same object. Strictly speaking, there is no error but Hibernate does send the same SQL multiple times and places unnecessary load on the database.

Please look at this timeline

0ms - Request from user A comes in asking for a page that requires a specific object. Our code queries Hibernate. Hibernate determines that the object isn't cached and asks the database for it. (The database will need 10ms to return the row for the object.)

7ms - Request from user B comes in asking for the same page. Hibernate can't find the object in the cache and asks the database for it...

10ms - Database returns result for first query. Hibernate places object into second level cache, returns it to our app. We render page and return to user A.

14ms - Request from user C comes in asking for that page. Hibernate finds the object in the cache, returns it to our app. We render page and return to user C.

17ms - Database returns result for second query... we return page to user B.

In our opinion this is not optimal and Hibernate should not emit the query at 7ms but rather realise that a query for that object is in progress and block this query internally until the object is retrieved and placed in the cache. That way we would half the load on the database and return the page to user B earlier.

In real production use the issue would be more pronounced and we'd see not only two but a large number of parallel db queries for the same object. In fact, the number of parallel requests is larger than the size of our connection pool, which means the queries are processed in serial batches, each the size of the connection pool.

Has anybody seen this before? Are there known workarounds?

First, what type of caching are you using (read-only, nonstrict-read-write, or read-write)? This has a big impact on the behavior of the cache. Additionally, are you using a query cache, or loading by identifier? This also has an impact on how the cache behaves

Second, consider that that your database is only one resource in your application. If Hibernate forced queries to block until the initial query completed execution an populated that cache, you'd have n-number of requests tying up your app server.

Two possible solutions for you:

1.) Preload your most frequently used cached data on startup. This will mimize the behavior your seeing. This can be done by executing a query to load the entities in question.

2.) increase the timeout on your connection pool so that callers will block longer until connection is returned to the pool.

Ryan-

Thanks for your quick answer.

We're using read-only caching and a mix of loading by identifier and named queries.

I don't understand the point you make regarding tying up the server. If we send the same query 10 times, these requests are tied up for even longer than if they only block until the first query returns. That's what I described in the timeline in the original post. (The request from user B is blocked for too long.)

Regarding the proposed solutions:

1) Unfortunately it's not really possible to know which objects will be the most frequently used ones on a given day. We really rely on user requests to populate our cache. And there are too many objects to load the entire table into memory at startup.

2) The issue is that we have to meet certain performance requirements and running multiple identical queries at the same time seems like a bit of a waste of resource. We'd really like to avoid the unnecessary queries.

Hello

I'm having the exact same problem. Has anyone found a solution for this?
Is BlockingCache of ehcache a solution to this problem?

thanks
Ioannis