As you all know, Hibernate introduces overhead to basically all operations on database due to management of internal cache and object state.
What we have currently in our application is that we read data using plain SQL (JDBC) and use Hibernate for saving and updating. Reason is that we need to load a lot of information in every run of calculation but update only a limited part.
Now, we know that this approach is not really the cleanest and we did some tests where we tried to fine-tune Hibernate’s reading but what we have achieved is following:
Read time JDBC (session.doWork): 23 s
Read time Hibernate (session.createQuery with lazy fetch): 94 s
It seems to us that existing overhead is due to Hibernate’s additional processing and we were wondering if parallelizing the read itself could be of any help (we are reading a lot of tables which we could do in parallel)? Are Hibernate’s session and transaction designed to be used from multiple threads safely?
Also, if you have any other idea, what could help to speed up this ready, we would be thankful.
It depends. If your database is clustered or different tables reside in different table spaces located on different physical disks or machines, parallelization might speed up things. Otherwise I/O is the bottleneck.
Also make sure your queries are compiled once and reused, the parsing/compilation phase in the database server may take some time (but can actually be parallelized successfully because this part is CPU-bound).
Absolutely not. Sessions and transactions in Hibernate are inherently bound to a database connection. And the connection is single-threaded.
use prepared statements/compiled queries to avoid compilation overhead in DBMS
experiment with L2 and query cache in Hibernate
make sure your connection pool is configured properly
monitor GC activity and memomry consumption, maybe your Hibernate session is growing too large?
consider stored procedures, they tend to be much faster