1.4, Performance issues, hibernate parameters not being honored

[hans]

Hi,

We experienced a performance downgrade moving from 1.2.5.3 to 1.3 and then 1.4, we found that the new versions don't honor hibernate.max_fetch_depth=1 in application.conf, wich we  have been using for many years.
Fortunately the standard for java applications is to honor configuration files over programatic configuration, hibernate is no exception. To fix this, create an hibernate.properties file in the classpath with the right values. To solve create a file called hibernate.properties  with content:

hibernate.max_fetch_depth=1

And put it in the app folder.

To find this, we enable full logging of hibernate following the same principle using a log4j.properties file.

Bye
Hans Poo

[Scott Rippee]

Thanks for your insights.

[Scott Rippee]

Hans,

I've added hibernate.max_fetch_depth=1 to my hibernate.properties file, but I'm still seeing an increased number of database calls that's also more than doubling my avg db response time.  I'm not sure if it's because it's fetching to more than 1 deep or if it's doing an eager fetch when it used to be lazy.  I can tell from newrelic that it's fetching from 2 tables that were not fetched from in 1.2.7.  What should I look for in the logs to determine if it's doing a deep fetch? 

Thanks

On Tuesday, November 10, 2015 at 1:22:48 AM UTC-8, hans wrote:

[hans]

Scott,

You can activate debuSQL from application.conf and then look for the logs.
Database low level logging may be an option, with postgreSQL we activate log_statement = 'all'   in postgresql.conf and then instruct postgres to reload configuration issuing an HUP signal, this is some bash code:

vim /etc/postgresql/9.3/main/postgresql.conf
grep log_statement /etc/postgresql/9.3/main/postgresql.conf
log_statement = 'all'            # none, ddl, mod, all

kill -HUP `cat  /var/run/postgresql/9.3-main.pid`
tail -f /var/log/postgresql/postgresql-9.3-main.log   |egrep -v PKTABLE_CAT\|TABLE_CAT\|nspname

As you see in the tail command we exclude metadata queries by hibernate.

Then you can start in debug mode your app step by step and keep atention to the queries that appear after the instructions you want to monitor,
for updates you may isse a JPA.em().flush() to force the database access after and update.

The JPA specification stands some rules for example: @ManyToOne are loader Eagerly and @OneToMany area lazy  loaded.

As i said before  our applications almost freeze without max_fetch_depth setted.

Good Luck
Hans

[Scott Rippee]

I ended up resolving the issue with extra queries.  I couldn't get the hibernate.properties to have an effect, but I ended up setting db.default.hibernate.max_fetch_depth=1 and I'm no longer running with 2 times the number of queries to my DB in dev.  I had the hibernate.properties file in my conf dir and noticed later that you said it should be in the app dir so maybe that was the problem.

Thanks

[hans]

Scott,

Yes, it's standard to use the java classloader to load the property files, the app folder is in the classloader so, you can put there your custom hiberante, c3p0 or log4j files..

Good luck,