Так?
from User u
left join fetch u.posts
left join fetch u.categories

SkyFireorg.hibernate.loader.MultipleBagFetchException: cannot simultaneously fetch multiple bags
Есть такое. Bag это не упорядоченая коллекция в хибернейт. Дело в том, что когда запускается join на несколько коллекций, то хибер не может из результатов запроса понять где какой user.id, чтобы правильно распихать результат по коллекциям.
Один из вариантов решения это замена Bag, на упорядоченый List. Для этого нужно в маппинге указать, как именно упорядочена коллекций.

http://stackoverflow.com/questions/13334831/multiplebagfetchexception-thrown One way to do this is by specifying the Hibernate specific @IndexColumn or the JPA standard @OrderColumn on the relations.

Давайте с моделью сначала разберемся.
То что категория ничего не знает о юзере - это мне понятно. Это логично.
Откуда вот только тогда у категории user_id - этого я не понимаю. Т.е. должно быть many-to-many.
И следующее. У всех категорий одного юзера - все user_id одинаковые. Поэтому сортировка по ним бессмысленна.

Логично попробовать
@OrderColumn(name="id")

JDK/bin/jvisualvm
http://habrahabr.ru/post/61857/

пролетевший Здесь засада на уровне SQL. такой запрос возвращает строки для каждого поста со всеми категориями ( картезианское произведение ). 100 постов и 100 категорий это уже 10000 строк.
По-моему модель, в котором коллекции зачастую имеют десятки элементов и более это уже как минимум странно. Возможно даже глупо. Это всё равно что в отношении "Автомобиль - Район Регистрации" в "Районе" завести коллекцию "Автомобилей".

пролетевший
Потом хибер пытается их собрать вместе удаляя лишнее, поэтому и ругался на Bag.

На Bag он ругался не из-за количества, а из-за того что в неупорядоченых списках он не может правильно найти нужные FK из результата запроса.

пролетевший
Больше 2х таблиц в join пихать надо с большой осторожностью.

Хотелось бы уточнить: больше двух джоинов для ассоциаций one-to-many.

пролетевший
Лучше грузить lazy с Batch Fetch .
Оффтоп, недавно настраивали производительность в приложении и обнаружили что MS SQL Join для небольшой выборки делает в несколько раз медленнее, чем 2 отдельных запроса. основная база около 10 млн записей, на каждую в среднем 20 записей в дочерних таблицах. Для обработки выбираются 4 записи из основной таблицы, ц дочерними коллекциями. Удаление любовно составленных join fetch улучшило среднюю производительность в 5 раз.
Всё верно. Спасибо за коментарий. Я сразу про это как-то не вспомнил.

SkyFireСпорный вопрос как мне кажется, сущности бывают разные.

Ну, давайте поспорим. В реальной жизни у юзера может быть сколько угодно постов. Т.е. у вас User.posts безразмерный список!
Делать join на эту коллекцию это за гранью разумного.
Даже lazy делать нужно с предельной осторожностью, потому что не факт что постраничная загрузка данных в этой коллекции будет работать. В противном случае мы отхватываем баги, когда неожиданно сервер будет уходить в OOME случайно загрузив User.posts.


SkyFireА по теме, с @OrderColumn так ничего и не вышло, к сожалению разбираться в чём проблема времени совсем нет. Проблема решилась заменой List<Category> на Set<Category>.

Да. Точно. Это второй рецепт, про который я успешно забыл.