Develop Reference

Hibernate JPA EntityManager.createQuery() performance

I have a query which has 2 'in' Clauses. First in clause takes around 125 values and second in clause of query takes around 21000 values. Its implemented using JPA CriteriaBuilder.
Query itself executes very fast and return results within seconds. Only problem is entityManager.createQuery(CriteriaQuery) takes around 12-13 minutes to return.
I search all over SO, all the threads are related to performance of Query.getResultList. None of them discuss about performance of entityManager.createQuery(CriteriaQuery). If you have seen such behavior earlier, please let me know, how to resolve it.
My JDK version is 1.7. Dependency version of javaee-api is 6.0. Application is deployed on JBOSS EAP 6.4. But that's not the concern as of now, as I am testing my code using junit using EntityManager connected to actual Oracle database. If you require more information, kindly let me know.

A hybrid approach is to dynamically create a query and then save it as a named query in the entity manager factory.
At that point it becomes just like any other named query that may have been declared statically in metadata. While this may seem like a good compromise, it turns out to be useful in only a few specific cases. The main advantage it offers is if there are queries that are not known until runtime, but then reissued repeatedly. Once the dynamic query becomes a named query it will only bear the cost of processing once.
It is implementation-specific whether that cost is paid when the query is registered as a named query, or deferred until the first time it is executed.
A dynamic query can be turned into a named query by using the
EntityManagerFactory addNamedQuery()
Keep us informed by the result and good luck

I observed that, having single query with 21 IN clauses (each with 1000 expressions) and all combined with OR clauses, made query run slower. I tried another approach of executing every IN Clause as a part of separate query. So these 21 individual queries performed better overall.
Another issue I observed was that Query with CriteriaBuilder was slow when result set is huge (something like 20K rows in result set). I solved this issue by adding query hint to my typed query:
TypedQuery.setHint("org.hibernate.fetchSize", 5000);
Hope it will help others.

Code in Hibernate is not expected to be used for binding lots of params:
for ( ImplicitParameterBinding implicitParameterBinding : parameterMetadata.implicitParameterBindings() ) {
implicitParameterBinding.bind( jpaqlQuery );
}
Unfortunately you need to find different approach if you want to do something similar.

Hibernate Named Query Vs JDBC Query Performance [duplicate]

This question already has an answer here:
Hibernate, JDBC and Java performance on medium and big result set
(1 answer)
Closed 8 years ago.
My requirement is to get only the availability of records (not getting values). For this scenario,my problem is that what can be the better solution to improve performance between the JDBC query and the HQL Named query.
As I think,since named queries are loaded at the time of hibernate factories are loaded and therefore, it can be faster than jdbc.
Please not that This is not a normal HQL query, here I am asking about the Named Query.
Normal HQL and Named query can have different performance. Most of questions and answers are about normal HQL. My point here is the NAMED QUERY .

Hibernate is excellent . But most have problems with using criteria queries because they do not understand it should only be used with a small number of tables like 5 or less. If you are doing something in the enterprise level use HQL queries you have all the power of jdbc. Also the learning curve is high but once you learn nothing can compare.

I assume that your question is “which option you should choose between JDBC and Hibernate”.
First of all, With HQL you have your query ready with you and the query will not be going to be generated for every request. But In case of native SQL in hibernate , the query will be generated on demand if I’m not wrong.
Same with JDBC. If you use PreparedStatement , your query will be generated once in its life cycle. Almost both are same. By the way you have option to tell hibernate that you need the queries to be generated at start up of ORM engine or not. In JPA annotations you can use dynamic = true at #entity annotation.
If you already Hibernate/JPA infrastructure in your project make use of it else go with plain vanilla JDBC option.

postgres 'WITH' clause with jooq

Hell, I can't find a way to use the postgres 'WITH' clause with JOOQ.
Could you please let me know if it's supported by JOOQ?
Thanks

Common table expressions (the "WITH clause") are currently not supported in jOOQ. There is a pending feature request on the jOOQ road map for CTE's: #454. As of jOOQ 3.0, there are currently no plans of actually supporting it, though.
(Your best option to push things a little bit is to discuss this topic on the jOOQ user group)

IBM DB2 9.7 Error code 840, select statement list is too large

We are using Hibernate with IBM DB2 9.7. The database gives error about Hibernate generated too large select statement list (including a lot of joins). The error code is 840. Can something be done to fix this? I know the generated select list is very long, but can Hibernate be set to split it into parts or something?
Edit: I reopened this since the problem seems to be a bit larger. So there is a JIRA issue (now rejected) at https://hibernate.onjira.com/browse/ANN-140.
So the problem is that with Hibernate Annotations, it is not possible to add discriminator with Join strategy. XML configuration however does support this.
Pavel nicely states the problem in the above link discussion like this:
"It would be nice to see how the problem with the multiple joins is faced when the
underlying DB has restriction on the number of joins one can execute in a single SQL?
For instance MySQL seems to allow only 31 joins. What happens if the class hierarchy
has more than 31 sub-classes?"
An the above is the very problem I am having. We are using annotations and the subclasses are quite a few, creating massive amounts of joins, breaking the DB2 statement.
Any comments on this? I could not find a direct solution either.

Hibernate has few fetching strategies to optimize the Hibernate generated select statement, so that it can be as efficient as possible. The fetching strategy is declared in the mapping relationship to define how Hibernate fetch its related collections and entities.
Fetching Strategies
There are four fetching strategies
fetch-”join” = Disable the lazy loading, always load all the collections and entities.
fetch-”select” (default) = Lazy load all the collections and entities.
batch-size=”N” = Fetching up to ‘N’ collections or entities, Not record.
fetch-”subselect” = Group its collection into a sub select statement.
For detail explanation, you can check on the Hibernate documentation.

OpenJPA dirty read hint

We've got the following DAO stack:
DB2 9.7 Express-C
OpenJPA 2.0.1
Spring 3.0.5
Bitronix 2.1.1
How do you specify OpenJPA to add WITH UR sql clause to the end of the query?
I'd browsed sites and manuals alike for days, it should be something like this:
Query q = em.createQuery("select m from Magazine m where ... ");
q.setHint("openjpa.FetchPlan.ReadLockMode","WRITE");
List r = q.getResultList();
but alas, I've been unable to find a working OpenJPA property that would be passed as setHint() argument and yield WITH UR as result, so I use SpringJDBC queries which I unfortunately can't use any longer.
Any ideas? Thank you very much

OpenJPA doesn't support using the WITH UR clause with JPQL. You could always use a native query for this functionality.

I'm having quite a similar problem now — it would seem that setting:
query.setHint("openjpa.FetchPlan.Isolation", "READ_UNCOMMITTED");
would do the trick. Unfortunately, the source code reveals that the constant withURClause from org.apache.openjpa.jdbc.sql.DB2Dictionary is never read.
Additionally OpenJPA never takes into account a fetch plan hint if the query is not FOR UPDATE. I have a select statement that gets blocked on exclusive locks and it could really work with uncommitted data — a no-go with OpenJPA.