QueryStatistics's getExecutionMinTime() return Long.MAX_VALUE instead of zero when execution count is zero and cache hit is greater than zero

Description

Introduction / Summary

QueryStatistics initializes the executionMinTime field to Long.MAX_VALUE. When the execution count is zero, this causes getExecutionMinTime() to return Long.MAX_VALUE instead of an expected value of 0 because the initial value has not yet been updated but a cache hit has already been done.

Test case

This can occur with two applications based on Hibernate and having its EhCache synchronized in replication mode (e.g. using JGroups): the first application does a query with query cache enabled (generates a miss, an execution and a put in the query statistics), then second application query cache is synchronized by replication of the query result (an implicit put without updating the second application query statistics). Finally, the second application does the same query (this generates a hit, but no execution): getting the minimum execution time will return Long.MAX_VALUE.

Location in the source code

The issue occurs in the new Hibernate 4 Beta's ConcurrentQueryStatisticsImpl as well as in current Hibernate 3.6's QueryStatisticsImpl and in older versions, e.g. Hibernate 3.3's QueryStatistics.

Solution

To be corrected, getExecutionMinTime should be corrected to return the executionMinTime only if the execution count is greater than zero, otherwise it should return zero. For example in Hibernate 3.6:

should be replaced by

Also the toString() method should call the getExecutionMinTime() method instead of using the underlying executionMinTime field.

Environment

Hibernate (at least 4.0.0 Beta5, 3.6.6, 3.3.1), EhCache 2.4.3, JGroups 2.12.1, DB2

Activity

Show:
Julien Kronegg
August 12, 2011, 4:58 PM

This is a regression introduced in

Steve Ebersole
October 27, 2015, 7:15 PM

This bug report does not indicate that the reported issue affects version 5.x. Versions prior to 5.x are no longer maintained. It would be a great help to the Hibernate team and community for someone to verify that the reported issue still affects version 5.x. If so, please add the 5.x version that you verified with to the list of affected-versions and attach the (preferably SSCCE) test case you used to do the verification to the report; from there the issues will be looked at during our triage meetings.

For details, see http://in.relation.to/2015/10/27/great-jira-cleanup-2015/

Steve Ebersole
October 28, 2015, 3:25 AM

As part of verifying that this issue affects 5.0, please just set the "Affects version". Leave the "verify-affects-5.0" label and leave the issue in "Awaiting Response" status; these are critical for us to be able to track these verifications and triage them. Thanks.

Julien Kronegg
October 28, 2015, 8:02 PM

The corrresponding class in 5.0 org.hibernate.stat,internal.ConcurrentStatisticsImpl does not implement a method to return the minimum execution time (e.g. no getQueryExecutionMaxTime). Thus, version 5 is not impacted by this issue.

Steve Ebersole
October 29, 2015, 4:10 AM

Thanks for verifying Julien!

Out of Date

Assignee

Unassigned

Reporter

Julien Kronegg

Fix versions

None

backPortable

None

Suitable for new contributors

Yes, likely

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Minor