Lazy loading зависит от базы данных?

Question

Мы сталкиваемся с очень запутанной проблемой в нашем приложении, которая разработана как трехуровневое приложение с использованием * Spring-Data JPA (1.8.2.RELEASE), Hibernate (4.3.10.Final) в слое данных * Весна управляется Pojos (@Service beans) на уровне обслуживания * Калитка (7.2.0) в слое GUI

Я знаю, и я знаю о проблемах, которые могут возникнуть при использовании управляемых bean-компонентов JPA в слое GUI (Lazy loading, equals , hashcode и т. д.). Чтобы избавиться от этого, мы используем Wickets LoadableDetachableModels для перезагрузки каждого отдельного объекта во время каждого запроса.

Теперь у нас есть страница, на которой пользователь может выбрать сущность внутри дерева. Объект инкапсулируется в LoadableDetachableModel, как упоминалось. Этот объект имеет отношение 1: n к другому объекту. При выборе объекта через дерево отношение типа 1: n обращается к известному исключению org.hibernate.LazyInitializationException: failed to lazily initialize a collection of role: com.isb.bppm.wm.model.Product.children, could not initialize proxy - no Session.

Это очень запутанно, поскольку это происходит только при настройке DB2 как базы данных. Для локального развития мы используем в памяти apache derby, где тот же код не приводит к указанному исключению. Мой анализ до сих пор оставляет базу данных только как разность между двумя конфигурациями. Позвольте мне еще упомянуть, что мы используем Springs OpenEntityManagerInViewFilter для каждого запроса, поэтому ситуация, когда сеанс не открыт, никогда не должен происходить.

Неужели кто-то из вас сталкивался с подобными проблемами и может дать нам подсказку, что может быть не так?

Answer 1

Благодаря Торстену я проверил наш код для моделей, которые не были должным образом отделены. И действительно, это был правильный намек. Наше собственное внедрение LoadableDetachableModel использует equals и hashcode, как и org.apache.wicket.model.Model. Это привело к тому, что объект модели был прикреплен сразу после его отсоединения, поскольку регистратор, говорящий, что модельный объект был отсоединен, использовал hashcode модели в комментарии к журналу.

Исправлено это путем реализации equals и hashcode путем проверки идентификатора объекта, который является членом нашей реализации loadableDetachableModel. Эти серверы хорошо для нас, поскольку идентификатор гарантированно не будет нулевым и уникальным, конечно.

В любом случае остается открытым вопрос, почему только изменение соединения с базой данных выявило эту проблему?