[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2399) FlushMode.AUTO practically unusable - should not flush before EVERY query

[Armin Haaf (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35055#action_35055 ] 

Armin Haaf commented on HHH-2399:
---------------------------------

we just migrated from hibernate 3.2.7 to hibernate 3.3.2 and got big performance problems with flushmode.auto

a service call used to take 10 seconds now takes more than 5 minutes (transaction timeout!)

the use case:

iterate over 500 elements, do a query and create a new entity for every element.

the query is a simple index lookup query and takes usually 5 milliseconds. 
After the 250. iteration, this simple query takes 3 seconds and further rising!!

After changing the flush mode to always, the problem vanished.

I think this issue is not only a major improvement, it is at least a critical bug, for us it is a blocker and we cannot rollout -> we have not found a way to set the default flushmode to always in a jpa environment....

 



> FlushMode.AUTO practically unusable - should not flush before EVERY query
> -------------------------------------------------------------------------
>
>                 Key: HHH-2399
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2399
>             Project: Hibernate Core
>          Issue Type: Improvement
>    Affects Versions: 3.1.3, 3.2.0.ga, 3.2.1, 3.2.2
>         Environment: PostgreSQL 8.1.5, JDBC 2 and 3, Linux kernel 2.4.x, 2.6.x, Java 1.5.0_09
>            Reporter: Piotr Kołaczkowski
>         Attachments: hbtest.zip
>
>
> The method flushIfRequired seems to flush before every query execution, even though there wasn't anything changed to the objects in the session, and the objects in the session are of different class than the object(s) queried. When having more than a few such objects in a session, it may lead to large, unneeded overheads (I noticed 10-200 times slowdown on simple queries). Our system uses many fast queries, that uasually return only one result or few results. The average query durations on different levels, measured by System.nanoTime() (see the attachment):
> - database level: 0.05 ms 
> - pure JDBC code, prepared statements: 0.2 ms 
> - pure JDBC code, no prepared statements: 0.7 ms
> - not cached hibernate query, no other objects associated with the session: 1.3 ms
> - cached hibernate query, object in the session cache, no other objects associated with the session: 1.1 ms
> - cached hibernate query, 10000 very simple objects of some other class in the session: >50 ms
> 10000 may seem large, but note these were very simple objects, having only 2 properties. On our production system we have classes with many properties, and even 20 objects in a session can cause a sub-millisecond query to run longer than 5 ms. We switched to FlushMode.COMMIT, and now the performance is much better. 
> Can you do something about this? As far as I've read in JIRA, a similar issue exists in Hibernate 2.x, and is still OPEN / UNRESOLVED.
> BTW. Why is the 1st level cache so slow in my tests? Why reading just a 2 field object from the database cause so much overhead over pure JDBC? What am I doing wrong? 
> There is so much marketing about using cglib reflection optimizer in the performance FAQ but even if I retrieved these objects using JDBC and reflection, I would achieve much better performance. After all 1 ms is very much time, if getting results from DB and sending them to JVM lasts 0.2 ms.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira