For all page hits where nothing is modified, do the following at the beginning of the session:
Session s = ObjTypeDAO.getInstance().getSession();
s.setFlushMode(FlushMode.NEVER);
Anyplace you execute a Query that will likely be repeated in the near future, make sure to call:
query.setCacheable(true);
It won't be cached otherwise.
In hibernate.cfg.xml:
Set the following to true while debugging so you can see when a page hit causes excessive sql queries:
<property name="hibernate.show_sql">true</property>
Set the following to true:
<property name="hibernate.cache.use_query_cache">true</property>
Set this to make batch updates larger:
<property name="hibernate.jdbc.batch_size">20</property>
Set this to true:
<property name="hibernate.cglib.use_reflection_optimizer">true</property>
Set this to true if your DB supports it:
<property name="hibernate.use_outer_join">true</property>
Customize c3p0 settings:
<!-- configuration pool via c3p0 (additional info: http://www.hibernate.org/214.html)-->
<property name="c3p0.idle_test_period">60</property> <!-- seconds -->
<property name="c3p0.acquire_increment">2</property>
<property name="c3p0.min_size">10</property>
<property name="c3p0.max_size">100</property>
<!-- This is the size of the preparedStatement cache. 0 means it's turned off. -->
<property name="c3p0.max_statements">100</property>
<!-- This is the idle timeout. It waits this long before closing idle connections. -->
<property name="c3p0.timeout">100</property> <!-- seconds -->
Set the cache to use ehcache or some other cache:
<property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
If you don't specify an ehcache.xml file, ehcache will default to using the ehcache-failsafe.xml that's in the ehcache jar file.
I like to have hibernate generate base classes that I derive the real objects from. This is how Hibernate Synchronizer works by default. However, there is one thing to watch out for. Hibernate checks "dirtiness" in some cases by doing a comparison of each field. As a result, if you overload a method in the derived class so that you return some other value besides what's in the hibernate base class then Hibernate will mistakenly think the object needs to be saved to the DB.
That caused me a horrendous amount of extra effort because it was doing updates (with unchanged information). The result was lots of pointless updates. It's not hard to detect though. Just watch the sql output in the log files to see if updates occur for read-only pages.
Session s = ObjTypeDAO.getInstance().getSession();
s.setFlushMode(FlushMode.NEVER);
Anyplace you execute a Query that will likely be repeated in the near future, make sure to call:
query.setCacheable(true);
It won't be cached otherwise.
In hibernate.cfg.xml:
Set the following to true while debugging so you can see when a page hit causes excessive sql queries:
<property name="hibernate.show_sql">true</property>
Set the following to true:
<property name="hibernate.cache.use_query_cache">true</property>
Set this to make batch updates larger:
<property name="hibernate.jdbc.batch_size">20</property>
Set this to true:
<property name="hibernate.cglib.use_reflection_optimizer">true</property>
Set this to true if your DB supports it:
<property name="hibernate.use_outer_join">true</property>
Customize c3p0 settings:
<!-- configuration pool via c3p0 (additional info: http://www.hibernate.org/214.html)-->
<property name="c3p0.idle_test_period">60</property> <!-- seconds -->
<property name="c3p0.acquire_increment">2</property>
<property name="c3p0.min_size">10</property>
<property name="c3p0.max_size">100</property>
<!-- This is the size of the preparedStatement cache. 0 means it's turned off. -->
<property name="c3p0.max_statements">100</property>
<!-- This is the idle timeout. It waits this long before closing idle connections. -->
<property name="c3p0.timeout">100</property> <!-- seconds -->
Set the cache to use ehcache or some other cache:
<property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
If you don't specify an ehcache.xml file, ehcache will default to using the ehcache-failsafe.xml that's in the ehcache jar file.
I like to have hibernate generate base classes that I derive the real objects from. This is how Hibernate Synchronizer works by default. However, there is one thing to watch out for. Hibernate checks "dirtiness" in some cases by doing a comparison of each field. As a result, if you overload a method in the derived class so that you return some other value besides what's in the hibernate base class then Hibernate will mistakenly think the object needs to be saved to the DB.
That caused me a horrendous amount of extra effort because it was doing updates (with unchanged information). The result was lots of pointless updates. It's not hard to detect though. Just watch the sql output in the log files to see if updates occur for read-only pages.
Version 5.1 last modified by Geoff Fortytwo on 11/07/2010 at 19:22
Document data
Attachments:
No attachments for this document