и где это надо использовать? в сессионном фасаде? или в самом ентити? как же инициализировать коллекцию все-таки? где именно это надо сделать? 

AntonSaburov, раскажите хотя бы кратко как это сделать и вы сделаете этот топик одним из самых популярных в интернете... Вы пользуетесь EJB3 в работе?

Ох, в реальном проекте у нас к сожалению используется еще EJB 2 и Hibernate (убедили начальство, что это проще). 

А вот для "Студенческого отдела кадров" я копался. Но вот описать прямо с нуля - сложно. В NetBeans это делается весьма удобно - наверно проще будет просто описать действия по пунктам. Постараюсь что-то простое выложить. А дальше уже самими копаться придется 

AntonSaburov, я копаюсь со страшной силой... сижу как раз в NetBeans - действительно удобно проектировать и компелировать, и деплоить.... но, не работает проект сделанный теоретически полностью правильно...

Добавлено через 2 минуты и 4 секунды
Как можно было сделать библиотеку Hibernate так, чтобы в одном классе нельзя было хранить две подгруженные постоянно коллекции? У меня в голове не укладывается... ведь это есть в каждом втором проекте... 

Это в каком смысле?

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

Добавлено через 29 секунд
да и вообще непонятно - как инициализировать их... 

может проблема и решена я так и непонял но насчет инициализации колекций меня в Hibernate спасло следующие
@Fetch(FetchMode.SUBSELECT)
@OneToMany(mappedBy = "...", fetch = FetchType.EAGER)

К сожалению не помогло... проблема остается открытой... 

хух... заработало... решение проблемы здесь - в этом блоге...
единственным недостатком является то, что приходиться отказаться от чистого EJB3 и использовать расширение Hibernate @IndexColumn... однако, странновато.... EJB3 сыроват...   

Как можно повлиять на связанные сущности при выборке?

Пример топискатера

Допустим выбираем Topic по id, а в posts нужно выбрать не просто все посты для темы с заданным id (что делается по умолчанию),  но и еще со status="А".

Если еще кто зайдет на эту тему, то мой совет такой.

Осоциации для бинов OneToMany и ManyToOne служат для того чтобы можно было пользоваться JPQL.

Пример:
Выбираем топики со статусом, к примеру, 'A'

or

or



Выбираем все посты где у топиков type = 1

or

or



Все запросы должны возвращать одно и тоже.
Последний запрос (без JOIN) может использоваться и без объявленных 
связей OneToMany и/или ManyToOne у соответствующих объектах.

Заключение:
OneToMany, ManyToOne, OneToOne, ManyToMany описывают поля для того, 
чтобы было удобно строить запросы на JPQL. JPA делает важную вещь - 
возвращает объекты!!!

Не кто не мешает по ассоциации OneToMany получить полную коллекцию 
связанных объектов и в цикле отобрать те что нужно, но такое решение при 
больших коллекциях, может дольше работать, но при достаточной мощности
сервера, это можно не заметить. Когда уже сильно будет тормозить, 
можно оптимизировать   


У меня волнует другой вопрос, с которым я столкнулся.
как избежать циклическую загрузки по связям ManyToOne.

К примеру выбираем "Клиентов" с базы, у клиентов есть "Менеджер", он в свою очередь принадлежит 
к "ГрупеМенеджеров", так же  у клиектов имеет "СтатусКлиента". 
В результате будет один запрос с таблици "Клиентов" и много одиночных запросов к таблицам:
 "Менеджер", "ГрупеМенеджеров", "СтатусКлиента".

если 1000 клиентов, 120 СтатусовКлиента, 40 менеджеров, 5 ГрупМенеджеров, 
и все записи из таблиц будут использоваться,
то получим минимум 1 + 120 + 40 + 5 = 167 запросов. TopLink сделает где-то 2000 запросов (у меня чуть другие данные, но суть та же)

Нашел ответ что нужно проектировать структуру базы с учетом связей. Как бы это хорошо,
но может есть более лояльный подход.

Другой вариант оптимизации использовать выбрав только то что нужно


Третий вариант оптимизации использовать LEFT JOIN FETCH:

этот вариант у меня не заработал в TopLink, в других не пробовал (пример для Hibernate).
у меня работает только один уровень с FETCH. (число одиночных запросов уменьшилось 

Четвертый вариант использовать FetchGroup, не совсем понял как его использовать 
и он зависит от реализации JPA.

Что делать в такой ситуации? 
Как избежать циклических запросов по связям ManyToOne когда в базе присутствуют сложные зависимости?