Давненько не приходилось останавливаться на проблемах с загрузкой ленивых объектов/коллекций, думал, что навсегда поборол для себя этот вопрос.
Есть связанные лениво объекты (причем, "один-к-одному"):
1.
2.
3.
4.
5.
6.
7.
8.
public class AuthUser implements Serializable, UserDetails {
...
@OneToOne(fetch = FetchType.LAZY, orphanRemoval = true)
@Cascade({CascadeType.ALL})
@JoinColumn(name="user_id")
private User user;
...
}
Ну, и, допустим, у User пара полей - field1 и field2.
Есть ДАО-слой, где я получаю объект AuthUser, типа такого:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
public class AuthenticationDAOImpl implements AuthenticationDAO {
private SessionFactory sessionFactory;
public void setSessionFactory(SessionFactory sessionFactory) {
this.sessionFactory = sessionFactory;
}
public AuthUser findAuthUser(String username, Object someParameter) {
List<AuthUser> users = sessionFactory.getCurrentSession().createQuery("...").setParameter(...).list();
...
}
}
Естественно, реализовываю OpenSessionInView, правда, не через фильтр, а через интерцептор, что совершенно не меняет дела.
Во вьюшке - JSP - хочу получить поле authUser.user.field1 ...
Получаю ошибку
LazyInitializationException: could not initialize proxy - no Session
Паттерн OSIV (фильтр или интерцептор) срабатывает - это видно по стеку ошибки. Если я дебагом поставлю точку останова в методе ДАО findAuthUser, то все работает нормально - страничка отображается нормально, все "срослось". Убираю точку останова - исключение.
Полночи просидел, не хотел напрямую идти с вопросом, и нашел решение полутыком-полунаитием, исследуя спринговский пакет org.springframework.orm.hibernate4. В спринге при работе с 3-им хибером удобным и популярным было работать с HibernateTemplate, что, как я понял, не очень нравилось хибернейту (людям из), и похоже, в 4-ом консенсус был достигнут, и программеров обязали все же использовать sessionFactory.getCurrentSession(). Но в указанном пакете есть класс SessionFactoryUtils, у которого всего 4 метода, среди которых есть openSession(sessionFactory). Я так понимаю, этот статический класс оставили, чтобы не сильно ломать ту гибкость (или многообразие), которая была в 3-ем, типа, "и вашим, и нашим".
Решил не получать текущую сессию для получения объекта, а создать новую:
1.
2.
3.
4.
public AuthUser findAuthUser(String username, Object someParameter) {
List<AuthUser> users = SessionFactoryUtils.openSession(sessionFactory).createQuery("...").setParameter(...).list();
...
}
Так все замечательно работает - уже проверил 100 раз, не подвело ни разу. Но терзают смутные сомнения - не насоздаю ли я слишком много сессий при относительно большой нагрузке?
Насколько оправдано такое решение? Не может ли появиться ошибка на 101-ый раз?
P.S. Понятно, что с EAGER я бы даже этого вопроса не коснулся, это даже не обсуждается. Но а) интерес все же на гору взойти, а не обойти; б) с терминологией туговато, но - родительский объект (authUser) по логике не подлежит изменению, или, по крайней мере, просто обновляется и клиент всегда работает с реальным объектом, а вот с зависимым (user) может быть проблема - он не библиотечный - бизнес-слой может изменить зависимый объект и появляется необходимость всегда обновлять связи, и это может стать проблемой для многопоточного приложения, слишком скурпулезно надо отслеживать все изменения, а ленивость загрузки нивелирует проблему. Хотя я не буду утверждать однозначную правильность слов, это всего лишь мое понимание и выводы из того, чего я ничитался.
