SkyFireЕсть Scheduler который периодически что-то синхронизирует с другими БД (это не суть, просто чтобы было понятно что используется не только MVC).
Не суть, но головняк реальный.


SkyFireНа сколько я понимаю, сервисный слой не должен ничего знать о БД (это работа DAO), соответственно открывать там сессию не есть хорошо (поправьте если ошибаюсь).

Посыл правильный, вывод - ошибочный.
Итак - DAO инкапсулирует детали работы с источником данных (БД+JDBC). Сервису этих деталей знать не нужно. Это правильно.
Но сервис при этом тесно связан с ORM. Без этого, к сожалению, уже никуда не дется. Нюансы ORM сервису нужны.
Открытие и закрытие сессии не нужно делать в сервисе. Это правильно. Но. Сессия, обычно, свяазана с транзакцией. Поэтому открытие и комит транзакции делает обслуживающий код вокруг сервиса, зачастую через AOP. А сессия тупо привязывается к текущему потоку. Нет сессии - создаётся новая. Есть сессия - берется текущая из ThreadLocal (а поток уже прибит к запросу из MVC или скедулеру)


SkyFire Получается что в DAO мы должны реализовать методы возвращающие нам наиболее полные, проинициализированные proxy domain объекты. К примеру для одной задачи ("пример с потолка") мне нужно вытащить из БД учеников класса. Ok, реализовали метод findУченики. Для другой задачи внезапно нам понадобились их родители, нет проблем делаем в DAO findУченинкиСРодителями.

На самом деле DAO - инкапсулирует работу с источником данных. А вот то что вы описываете, называется Repository. Этот паттерн инкапсулирует сложные запросы. В том числе и ORM запросы.

SkyFire Вопрос: Что делать если дальше Мне понадобиться вытаскивать учеников с родителями и их адресами и т. д. и т. п.?
Реализовывать очередной сто-первый метод в DAO что то вроде findУчиеникСРодителямиСАдресами?

Да. Это не так сложно, если использовать управление через Fetch/FetchMode. Можно пере-использовать одни и те же запросы, но в разных сервисных методах, указывать fetch для тех ассоциаций, которые вам нужно прогрузить сразу.


SkyFireКак быть если в сервисном слое на определённом этапе бизнес-логики мне понадобилось узнать адреса родителей, но вот незадача для поиска учеников я использовал метод findУченинкиСРодителями, и если я делаю обращение dao.getPuple().getParent().getAddress() - то ловлю LazyInitializationException.
"Сервис" это "простонародное" название паттерна, который у Фаулера называется Transaction Script. Из названия очевидно что Transaction Script реализует некоторую бизнес-транзакцию. Бизнес-транзакция зачастую связана с транзакцией в базе.
А если ещё открыть JavaDoc класса HibernateSession, то можно обнаружить что scope для сессии обычно совпадает со scope транзации. Поэтому вывод о том что Session создаётся и закрывается в DAO - ошибочен.
Сессия создаётся тогда когда она первыя раз нужна и закрывается, обычно, при выходе из метода Transaction Script, вместе с коммитом сессии и, затем, транзакции.

SkyFireМне кажется подход в создании методов в ДАО на каждый "чих" не правильный и не логичный (для чего вообще тогда этот ORM). Как поступаете вы в подобных случаях?
Criteria API, Repository. Актуальные версии Spring Data вообще имеют забавную фичу. Там запросы генерятся из имени метода и параметров. "не правильно" это какой-то мутные термин. Чем именно это плохо?

BlazkowiczА если ещё открыть JavaDoc класса HibernateSession, то можно обнаружить что scope для сессии обычно совпадает со scope транзации.
Полагаю очевидно, что имя класса Session, а не HibernateSession. Кто-то просто провтыкал пробелы и знаки пунктуацию.

SkyFireБлагодарю за столь развёрнутый и полный ответ. Очень многое прояснилось. Сейчас убрал из слоя "DAO" (Переименовал в Repository) все аннотации @Transactional и перенёс их в сервис слой - всё заработало.
В Spring Data есть много вкусного. Правда только для JPA API. Но можно с хибером и через него бодаться.


SkyFireНо вот вопрос, почему возникал LIE когда и в слое Repository и в сервисном слое были указаны @Transactional? На сколько я знаю по умолчанию транзакционный атрибут выставляется как "Required", что означает если уже открыта транзакция то будет использоваться область видимости существующей транзакции.
На то может быть несколько причин. Надо разбираться.
Первая - управление сессией, как-то отвязано от управления транзакцией. И не смотря на открытую транзакицю, сессия оказалась закрыта.
Вторая - часто бывает как раз во всяких скедулерах. Вызов метода произошел мимо Spring AOP прокси. Например, через this. Поэтому @Transactional успешно был проигнорирован.

SkyFireт.е. в данном случае транзакция будет проигнорирована?



Да. Типа этого. Зависит, конечно, от используемых фреймверков.

SkyFireПроверил в Spting 3.2 - LIE
Не подскажите какой подход будет правильным? Если в некотором методе (Task) мне нужно последовательно вызвать несколько методов этого же класса, но при этом одна общая транзакция не нужна.
Отделить Scheduled Task (методы запускаемые по расписанию) и Transaction Script (бизнес-транзакции). И тогда не будет этих проблемых вызовов через this. Можно было бы захачить, если бы спринг позволял нормально заинжектить ссылку на себя из контекста. Но, я не помню, реализована ли эта фича уже.

Вроде, ещё не сделали:
http://stackoverflow.com/questions/5107505/can-i-inject-same-class-using-spring
http://stackoverflow.com/questions/5152686/self-injection-with-spring
https://jira.springsource.org/browse/SPR-8450

LeonidvТак, насколько я понимаю, должна запуститься транзакция. Если Scheduler тоже каким-то образом имеет отношение к Spring'у.
SkyFire мне нужно последовательно вызвать несколько методов этого же класса, но при этом одна общая транзакция не нужна.