Hibernate cache
Caching and flushing
Monitor statistics in jboss jmx-console:
Hibernate
* name=statistics
Ehcache
Ehcache performance
Ehcache docs
Hibernate Caches
Hibernate cache documentation
Truly Understanding Hibernate Second-Level Cache
From above article:
The cache is holds strings, and serializable identifiers for relationships. The cache does *not* holding on to actual instances of the objects. Why is this important? Two reasons. One, Hibernate doesn't have to worry that client code (i.e. your code) will manipulate the objects in a way that will disrupt the cache, and two, the relationships and associations do not become 'stale', and are easy to keep up to date as they are simply identifiers.
The default setting is to not cache associations; and if you are not aware of this, and simply turn on caching quickly without really reading into how caching works in Hibernate, you will add the overhead of managing the cache without adding much of the benefits. After all, the primary benefit of caching is to have complex associations available without having to do subsequent database selects - as I have mentioned before, n+1 database queries can quickly become a serious performance bottleneck.
Other Info:
Hibernate SQLQuery.executeUpdate() clears all L2 caches, Query.executeUpdate() clears associated entity cache.
You can skirt the issue by:
1) manipulating via entities
2) using PreparedStatement
3) using Query instead of SQLQuery.
See post
The cache clearing occurs from org.hibernate.action.BulkOperationCleanupAction
Another post:
Another thing that is worth mentioning that can be very detrimental to 2nd level cache performance is executing native SQL queries. If you look deep in the depths of the Hibernate Query infrastructure (SQLCustomQuery, NativeSQLQueryPlan, BulkOperationCleanupAction), you will see that any time a custom SQL is run, it clears ALL your entity/collection caches.
The easiest way to see this is to turn on debug logging of the caches (either hibernate or ehcache/etc) and watch as all your cached data is dumped when a native SQL query is run. Yikes!
Other links:
understanding-caching-in-hibernate-part-one-the-session-cache
understanding-caching-in-hibernate-part-two-the-query-cache
understanding-caching-in-hibernate-part-three-the-second-level-cache
hibernate-query-cache-dirty-little
Bug fix
Monitor statistics in jboss jmx-console:
Hibernate
* name=statistics
Ehcache
Ehcache performance
Ehcache docs
Hibernate Caches
Hibernate cache documentation
Truly Understanding Hibernate Second-Level Cache
From above article:
The cache is holds strings, and serializable identifiers for relationships. The cache does *not* holding on to actual instances of the objects. Why is this important? Two reasons. One, Hibernate doesn't have to worry that client code (i.e. your code) will manipulate the objects in a way that will disrupt the cache, and two, the relationships and associations do not become 'stale', and are easy to keep up to date as they are simply identifiers.
The default setting is to not cache associations; and if you are not aware of this, and simply turn on caching quickly without really reading into how caching works in Hibernate, you will add the overhead of managing the cache without adding much of the benefits. After all, the primary benefit of caching is to have complex associations available without having to do subsequent database selects - as I have mentioned before, n+1 database queries can quickly become a serious performance bottleneck.
Other Info:
Hibernate SQLQuery.executeUpdate() clears all L2 caches, Query.executeUpdate() clears associated entity cache.
You can skirt the issue by:
1) manipulating via entities
2) using PreparedStatement
3) using Query instead of SQLQuery.
See post
The cache clearing occurs from org.hibernate.action.BulkOperationCleanupAction
Another post:
Another thing that is worth mentioning that can be very detrimental to 2nd level cache performance is executing native SQL queries. If you look deep in the depths of the Hibernate Query infrastructure (SQLCustomQuery, NativeSQLQueryPlan, BulkOperationCleanupAction), you will see that any time a custom SQL is run, it clears ALL your entity/collection caches.
The easiest way to see this is to turn on debug logging of the caches (either hibernate or ehcache/etc) and watch as all your cached data is dumped when a native SQL query is run. Yikes!
Other links:
understanding-caching-in-hibernate-part-one-the-session-cache
understanding-caching-in-hibernate-part-two-the-query-cache
understanding-caching-in-hibernate-part-three-the-second-level-cache
hibernate-query-cache-dirty-little
Bug fix
Comments