Why is hibernation shutdown / order_inserts / order_updates disabled by default?

Question

Are there any reasons why hibernate batching / hibernate.order_updates / hibernate.order_inserts is disabled by default? Is there a drawback when you include a batch size of 50? The same goes for order_updates / order_inserts. Is there a precedent when you shouldn't include these features? Are there any effects when using these functions?

I can only see that these settings are very helpful when I need to reduce the number of queries that I need especially in a high latency cloud environment between my application and the database server.

Answer 1

Normally setting the batch size to the resonant size and order_insert , order_updates to true can significantly improve performance.

In all my projects, I use this configuration as the basis:

 hibernate.jdbc.batch_size = 100 hibernate.order_inserts = true hibernate.order_updates = true hibernate.jdbc.fetch_size = 400 

But, yes - when using batch processing you can use it . But it depends on the jdbc driver.

For example, the Oracle JDBC driver creates internal buffers for each PreparedStatement and reuses these buffers. If you call a simple update statement, you set some parameters using ps.setInt(1, ...) , ps.setString(2, ...) etc., and Oracle will convert these values ​​to some byte representation and saves in the buffer associated with this PreparedStatement and connection.

However, when your PreparedStatement uses a packet of size 100, this buffer will be 100 times larger. And if you have a connection pool, then for more than 50 connections there can be 50 such large buffers. And if you have 100 different statements using batch processing, all such buffers can have a significant memory impact. When you enable batch size, it becomes a global parameter - Hibernate will use it for all insertions / updates.

However, I found that in all my projects, improving performance was more important than the effect of this memory, and that is why I use batchsize=100 as my default value.

With order_inserts , order_updates , I think they are disabled by default because these settings only make sense when batch processing is enabled. When starting a batch, these orders are simply invoices.

For more information, see the Oracle reference documentation:

http://www.oracle.com/technetwork/topics/memory.pdf

in the section "Charging applications and memory usage".

==== EDIT 2016.05.31 ====

A word about the properties of order_inserts and order_udpates . Suppose we have entities A , B and save 6 objects in this way:

 session.save(A1); // added to action queue session.save(B1); // added to action queue session.save(A2); // ... session.save(B2); // ... session.save(A3); // ... session.save(B3); // ... 

after doing above:

• these 6 objects have generated identifiers
• these 6 objects are connected to the session (StatefulPersistenceContext: entitiesByKey, entityEntries, etc. /Hib.v3/)
• these 6 objects are added to the ActionQueue in the same order: [A1, B1, A2, B2, A3, B3]

Now consider two cases:

case 1: order_inserts = false

during sleep mode, sleep mode executes 6 insert instructions:

 ActionQueue = [A1, B1, A2, B2, A3, B3] insert into A - (A1) insert into B - (B1) insert into A - (A2) insert into B - (B2) insert into A - (A3) insert into B - (B3) 

case 2: order_inserts = true , tolerance allowed

now, during sleep mode, hibernate executes 2 insert commands :

 ActionQueue = [A1, A2, A3, B1, B2, B3] insert into A - (A1, A2, A3) insert into B - (B1, B2, B3) 

I researched this for Hibernate v3, I think Hibernate v4 uses ActionQueue in the same way.

Answer 2

Documentation here: https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/chapters/batch/Batching.html

says there may be a performance penalty for using these properties. I would suggest that this is the reason they are not installed by default.