MisterCleric, после нескольких перечитываний разобрался, в том, что ты хотел до меня донести - недельный отдых дает о себе знать, мозг еще не включился 
Итак по делу.

А допустим у меня есть несколько сущностей, который содержат коллекцию пользователей. Хочу я удалить одного пользователя из базы. Мне придется сперва из всех этих коллекций удалить пользователя, а потом уже удалить его из базы? Ерунда какая-то получается. 

MisterCleric,  что скажешь про orphan deletion? Я что-то почитал, но если честно что-то не очень понял.

Встает такой вопрос. Если столько проблем с этими коллекциями, удалением элементов etc. Надо ли вообще эти коллекции?
В чем удобство? . Да согласен. Но я так же могу написать простой запрос

Сразу отпадает проблема с ленивыми коллекциями и удалением элементов. Удалил 

И нигде больше не вылезет этот application. Или я не прав?

Короче я запутался 

Привет. Слушай, давай ты почитаешь
Java Persistence with Hibernate
страница 273. А потом попытаемся разобраться. 
Вряд ли я смогу своими словами более толково объяснить, чем там написано.
Все ты рассуждаешь правильно. И про коллекции и про ленивость, но у меня одно замечание:
Зачем так наворачивать  в одном PersistenceContext такую логику, что у тебя будет куча сущностей с коллекциями OneToMany да еще так, что придется убивать одну из сущностей, что может быть в этих коллекциях?

Последний твой пример абсолютно верный: но он естественно, будет работать верно, если ты ленивую коллекцию позовешь после удаления. Да еще, по-моему, придется перед вызовом ленивой коллекции или сразу после удаления вызвать


для насильного вызова всех предыдущих перзистенс-операций. Так как INSERT/DELETE/UPDATE по-умолчанию планируются для вызова при коммите транзакции.

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


Ну наверно так и буду делать.


Получится, что ассоциации у меня будут не bidirectional, а undirectional.
Цитата из книги

Может с логикой и все нормально. Бывает же такое как тернарное соединение и иногда без него никуда, особенно, если надо писать приложение на уже готовую базу. Проблема здесь заключается в том, как много сущностей и  их связок ты пытаешься использовать в одном PersistenceContext, может надо подумать о чем-то дискретном: одна бизнес-операция с транзакцией и PersistenceContext, а в ней немного кода использующего базу на все вот эти связки, что ты назвал. Врядли при работе с категориями тебе придеться работать с сообщениями пользователей.
.
Не всегда это плохо. У меня тут по каскадному удалению была тема. И как раз bidirectional выручил

Да, чувствуется, что не хватает теоритических знаний :(
Насколько я понимаю, PersistenceContext - это область памяти, где хранятся мои объекты в рамках одной транзакциb или сессии. Верно? Если так, то естественно в одном контексте не будет использоваться так много сущностей. Я понял, что ты хотел сказать.
Ладно, вечером попробую поэксперементировать с тестами. Еще отпишу чего-нить  Еще раз спасибо за помошь!

Да ты знаешь: не всегда. У меня получилась такая логика в приложении, что уже не рад: банк, программы страхования, группы рисков, тарифы, опросники, ответы на опросы, полис, физ. лицо. 
И иногда получалось такое несуразное, что мама не горюй: так оно не укладывалось в голове. В одной транзакции удалял ответ из коллекции - было все ОК(Это логика анкеты). В другой транзакции по логике "невидимых вопрос" вызвал тот же метод удаления ответа из коллекции получил эксепшн, что-то типа in detached state. В общем надо как-то приводить логику своего приложения к какому-то нормализованному виду, как это делается в базе введение примари кеев одним полем. Но на это все надо времени, естественно...