Лучше решение, чтобы избежать «org.hibernate.LazyInitializationException: не удалось инициализировать прокси - нет Session» в модели Ленивый

Question

«типо» имеет один «Profissão:»

@ManyToOne(fetch = FetchType.LAZY) 
    @JoinColumn(name = "id_profissao", nullable = false) 
    public Profissao getProfissao() { 
    return profissao; 
    } 

Когда я попытался в DataTable просмотреть данные это отношение лица типо и Profissao связанные:

<p:dataTable var="lista" value="#{tipoBean.tipos}" id="tabelaTipos" 
      rows="10" paginator="true" widgetVar="tabelaTipos"> 

      <p:column headerText="Profissão"> 
       <h:outputText value="#{lista.profissao.nome}" /> 


</p:dataTable> 

DAO:

Criteria cri = session.createCriteria(Tipo.class) 
        .setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY) 
        .addOrder(Order.asc("nome")); 

    return cri.list(); 

Я получил эту ошибку ш idely обсуждается здесь: org.hibernate.LazyInitializationException: не удалось инициализировать прокси - нет Сессия

Итак, я реализовал это с использованием метода «Hibernate.initialize».

Criteria cri = session.createCriteria(Tipo.class) 
        .setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY) 
        .addOrder(Order.asc("nome")); 

      List<Tipo> tipos = (List<Tipo>) cri.list(); 

      for (Tipo t :tipos) { 
       Hibernate.initialize(t.getProfissao()); 

      } 

Это сработало, но есть лучшее решение для этого? Я не хочу использовать решение Eager. Любые решения?

Спасибо!

Answer 1

Сначала вам нужно определить, какой день вам нужен для страницы/стола. Эти данные должны извлекаться из db с помощью hibernate каким-либо образом, будь то объединение или отдельный выбор или запрос.

Теперь у вас есть два варианта:

1. получают данные в вас уровне службы до возвращения объекта в виде слой. Для этого вы можете указать FetchMode s (присоединяйтесь или выберите) по вашему запросу или воспользуйтесь Hibernate.initialize.
2. Используйте стратегию открытого сеанса в режиме просмотра. С помощью этого решения представление может загружать дополнительные данные, перемещая объектную модель. Если ранее ассоциация не была загружена, но представление вызывает геттер, спящий режим будет инициализировать прокси.

Второй вариант Pro: более гибкий: если вам потребуется больше данных в дальнейшем, вам не нужно менять уровень обслуживания. Это связано с тем, что руководитель сервиса не знает, какие данные используются. Con: сложнее найти проблемы с производительностью: поскольку представление загружает данные, когда это необходимо, основная часть данных может быть загружена после того, как ваш уровень обслуживания выполнил свою работу. Измерение времени отклика на уровне обслуживания часто может быть легко устранено путем добавления перехватчика. В зависимости от вашей технологии просмотра измерение времени рендеринга может быть намного сложнее.