Является ли производительность кэширования кэша на уровне сеанса по умолчанию Hibernate (5.2.5)?

Question

Я не уверен, что этот наблюдаемый эффект связан с кешем сеанса Hibernate, но он выглядит так. В настоящее время я запускаю тестовые блоки против базы данных базы данных H2 (v1.4.x/MVCC), хранящейся на SSD. Я вставляю строки 10k +, а производительность с «чистой» JPA очень плохой, и у меня есть один процессор, работающий на максимальной скорости, делая вставки «регулярных» строк со скоростью 200-300 в секунду. Теперь интересная часть: когда я завершаю каждую инструкцию insert («em.persist (...)») в отдельную транзакцию и «отключаю» сохраненный объект от менеджера сущности сразу после фиксации, скорость увеличивается в десять раз. Как-то Hibernate, похоже, забывает о сбросе сохранившихся объектов и накапливает их без каких-либо заметных ограничений.

Почему производительность по умолчанию настолько дрянной? Неужели никто не заботится об этом или что я здесь не так понял?

По какой-то причине Hibernate жалуется на то, что соединения JDBC не были в автоматическом режиме. Связано ли это?

Answer 1

Hibernate, кажется, забыл демпинг сохранялось объекты

Нет, он ничего не забыл. Это заставляет их управлять в сеансе нарочно, потому что это не будет нарушать его собственный контракт: вы должны иметь возможность изменять управляемый объект после его сохранения и сохранять эти изменения в базе данных. JPA будет совершенно бесполезным, если он вернет отдельные объекты.

Это не должно препятствовать явным образом их отсоединению, если вам нужно, as the documentation suggests doing, когда вам нужно вставить огромное количество элементов (это не вариант использования Hibernate/JPA).