Hibernate sessionFactory перестраивается для каждого модульного теста (с использованием Spring Framework)

Question

Я использую SpringT AbstractTransactionalDataSourceSpringContextTests для своих модульных тестов персистентности, и моя проблема в том, что мои тесты слишком медленные: 1 метод = 5 с, и каждый дополнительный метод занимает по крайней мере еще одну секунду У меня более 300 дБ таблиц, поэтому медленный запуск, возможно, понятен. Однако я просмотрел журналы, и одна из удивительных вещей заключается в том, что Hibernate sessionFactory перестраивается для каждого метода тестирования. И это половина стоимости выполнения каждого дополнительного метода.

Разве я не смогу повторно использовать оригинальный sessionFactory?

Я немного углубился в исходный код и не видел очевидного способа принудительного повторного использования sessionFactory.

Есть идеи?

И есть ли другие идеи по ускорению модульных тестов на устойчивость?

(Spring 2.5 и Hibernate 3.2ish, hsqldb)

Answer 1

Вы должны написать вспомогательный класс или около того, чтобы вы могли обернуть свой ISessionFactory API, и вам лучше сделать его статическим , так что он создается только один раз, так как этот API очень дорогой для создания экземпляра.

Answer 2

Весь наш SpringContext обновлялся каждый раз, что, как мне казалось, было неопределенно связано с каким-то динамическим жонглированием контекстом весны, которое мы делаем. Тем не менее, жонглирование выполняется отдельно для каждого класса, поэтому обновление каждого метода было совершенно ненужным.

«Решение», как оно есть, состоит в том, чтобы пропустить обновление контекста, которое позволяет избежать восстановления фабрики сеанса.

Я до сих пор не уверен, почему Spring чувствует необходимость восстанавливать фабрику сессий с нуля для каждого обновления. Я полагаю, что восстановление для них - это самый простой способ обновить сеанс, но, надеюсь, не самый быстрый.

Спасибо за ответы.

Answer 3

Вы должны попытаться найти место, где создаются sessionFactories (моя ставка была бы такова, что каким-то образом новый создается в каждом методе setUp ()). Затем вы можете переместить создание в отдельный класс, возможно, в статический метод, который внутренне гарантирует, что создан только один его экземпляр (вроде Singleton).