slippery 1) далее: но ваш подход не решает или я посмотрел 1 проблемы, а конкретно добавление в выборку созданных сущностей: "но вот добавлять которых нет, уже не совсем ясно, ведь запросы могли быть по условиям, а не простой селект всех из списка, а если по условии то не факт, что в результат выборки нужно добавить все новые объекты получаемого типа из мапа, может быть только половина подходит.
к примеру на первой вкладке добавили двух пользователей с именами Петя, Вася. А на второй делаем запрос "найти всех пользователей чье имя начинается на П" тогда в эту выборку нужно добавить только 1 пользователя из мапа, а не двух. "
Причем так как задача у меня стоит написать универсальный визард, то условий я не знаю заранее, имеется ли хорошее решения этой проблемы и если да, то какое????
Ну опять таки - через HQL это нерешаемо. Через сервисы - запросто. Делаете что-то типо getByNameStartWith(String startWith). Этот метод выполняет запрос к базе, потом анализирует содержимое контекста, и объединяет обе коллекции.

slippery 2) И еще, вы писали : "Теперь внимание - все HQL/SQL запросы, все критерии - НЕ ИДУТ через кэш первого уровня, они в него не смотрят. Они вытаскивают инормацию сразу из БД и только потом кладут ее в кеш. Поэтому, если вы что-то создали, но не сделали flush(), то нет никакого способа заставить ХИбер вытащить это через HQL запрос. Вообще никак."

но проведя эксперимент у меня получилось так:
get(A.class, 1);
исправил в нем какое-то поле
и после сделал так: createQuery("from A").list();
то в результате в списке объектов А будет объект с ид-1 с уже измененным значением поле. То есть хибер заменил объект из выборки на тот что хранится в памяти ну или смержил, внутренностей не знаю.

То есть получается что все же не минует кэш первого уровня, ведь измененный но еще не сохраненный в базу объект он подхватил из кэша! Почему в этом случаи это работает????Это немного другое. В этом сценарии вы сначала вытащили некий объект в сессию. Потом имзенили его, но не отправили изменения в БД. Потом вы снова вытащили этот же объект из БД. Хибер выполнил реальный запрос, стал класть результаты в сессию, заметил, что в сессии уже есть объект класса A с id = 1, и не стал перезаписывать его состояние. Так что это ожидаемо.

Ну и резюме: как я и думал, все проблемы у вас идут из-за неправильных решений при проектировании. Вы должны понимать, что сессия Хибера это абсолютно чужеродный объект в слое презентации. Сушности, прикрепленные к контексту Хибера это тоже чужеродные объекты для презентации, но при аккуратном использовании их можно все-таки сувать в PL.
То есть вы сознательно лишили себя необходимого интерфейса в видо DTO для перехода от доменной модели к PL и обратно, засунули в PL сессию Хибера и теперь мучаетесь с ней.
Выхода только два - либо идти моим путем и делать все по уму, либо придумывать всякие велосипедные или неестественные решения (например, как я привел выше - лезть в потроха Хибера). Третьего не дано.

Petro123- любой SQL запрос сначала делает flush, а потом сам запрос.Неверно. Никакого flush() не происходит. То есть, правильнее - it depends. В случае автора - с отключенным автоматическим flush(), его не будет.

slipperyи еще дополнение по второму вопросу: (по update объекты), то есть он кладет его в кэш и мержит с тем, что уже там есть, по правилу простой замены, типа тот что уже есть в кэше круче(новее/правильнее) берем его?Сессионный "круче" по дефолту. Но это, скорее всего, можно как-то регулировать. Может быть - setCacheMode() поможет, может еще как.

PEtro123- по умолчанию (если не отключал) - верноХз, надо тестировать. В случае SQL запроса - уверен на 95%, что это не так. По поводу HQL - просто сильно сомневаюсь.
Petro123- если отключил, то я читал что flush он падла и иногда делает :). Ты можешь поручиться что он сам ни разу не сбросит?Я не могу поручаться за чужой код. Откройте исходники и посмотрите.

Petro123svenomТретьего не дано.
эх... молодость...категоричность Ждем от вас других вариантов решения. Мои два по сути звучат так: либо дальше мучаться от неправильного решения, принятого ранее, либо же заменить его на правильное.

Petro123Концепция - отсоединил и присоединил В ДРУГОЙ ТРАНЗАКЦИИ И ХИБЕР-СЕССИИ.Плохая концепция, так как сессия для этого не предназначена. Если приходится отсоединять/присоединять сессию - это очень большой повод задуматься о правильности решения. Ибо сессия должна жить в пределах срока жизни транзакции. Действие "внес какие-то изменения, но в базу не сохранил" - это не транзакция, это просто некое промежуточное действие пользователя. Последние два предложения - ключ к пониманию проблемы автора.
Короче, попытка впихнуть невпихуемое.