Аргумент "мне так надо" не катит, это не аргумент вовсе. РАсскажите зачем вам это надо, наверняка есть человеческие пути решения вашей проблемы. Если действительно без этого никак, то убирайте @GeneratedValue и вставляйте значения ключа руками пот создании сущности. Иными словами - либо вы генерируете ключи только автоматически, либо только руками. Третьего не дано.

slipperyPetro123ну, и если твой шеф второй раз ставит неадекватную задачу (после автовкладок) - беги без оглядки.

))) да это все та же задача, только это уже конкретный момент в её решении для меня, думал есть простой ответ и не стал писать туда, так как ответ должен был решить проблему) тогда опишу применимо к той задаче. Ссылка на ту задачу: /topic/909083&hl=

Помните в конце был предложен вариант сбрасывать всю сессию перед каждым запросом в транзакцию и потом проводить откат чтоб изменения не вступали в силу. Ну так вот сущности я храню в отдельной в структуре, как предлагал svenom, перед запросом их сбрасываю провожу запрос и откатываю транзакцию и что происходит: пример теоретический естественно
1 действие: «найти последних 5 новых пользователей»
1.1 начало транзакции
1.2 добавление сущности «Пользователь» ему создается id, так как это сущность то save или merge чтоб добавить.
1.3 выполняется запрос : «найти последних 5 новых пользователей»
в результат запроса попадает наш новый добавленный пользователь с выделенным id = 5
1.4 откат транзакции
1.5 список передается на обработку

2 действие: «включить найденных пользователей в роль 1»
2.1 начало транзакции
2.2 добавление сущности «Пользователь» ему создается новый id отличный от id на шаге 1.3 и не равный 5
2.3 выполняется запрос : «включить найденных пользователей» !!! и вот тут и момент будет попытка включить в роль пользователя который был получен в запросе 1.3 с тем id. Так как результат того списка(1.5) подставляется в ну скажем так метод "включения пользователя в роль". А не того что создается сейчас на шаге 2.2 А пользователя с тем id = 5 вообще нет в системе, что естественно

Вот я и подумал выделать под сущности при сбросе собственной сессии id и потом перед каждым запросом вставлять их уже под этим id. Но я не могу убрать автогенерацию , так как сущность создается не только в моей задачи. А и другими людьми. А так как у меня как вы помните универсальный визард, то это касается вообще всех сущностей Есть какие-нибудь у кого мысли?Проблема высосана из пальца, ее по сути нет. Как должен работать ваш подход:
1. Начали транзакцию
2. Применили все изменения в правильной последовательности
3. Выполнили чтение
4. Закрыли (откатили) транзакцию.
Так вот, внимание на шаг 2 - здесь ни в коем случае нельзя никуда в JVM сохранять сущности со сгенерированными идентификаторами , по факту закрытия транзакции они должны быть отданы на растерзание GC.
Соответственно, на следующей транзакции вы прогоняете процесс по новой, получаете новые идентификаторы. Все, никакой проблемы нет.

slippery,
Ну вот вам пример, как это должно работать. Допустим, у нас есть сущности Employee(id, name) и Department(id, name). Вы хотите создать нового сотрудника Васю, прикрепить его к департаменту и суметь получить его в выборке по департаменту на следующем запросе. Как это сделать?
1. Создаем EmployeeVO, которому присваиваем имя Вася и какой-то собственный идентификатор (а не сгенерированный базой!). Поулчаем EmployeeVO(1, Vasia).
2. Добавляем его в список сотрудников департамента DepratmentVO.getEmployees();
3. Сохраняем эти VO в сессии.
4. Когда начинается новая транзакция, вы берете те VO, что должны быть сохранены в базе, перегоняете их в соответствующие сущности, сохраняете в базе, а потом сопоставляете идентификаторы VO и Entity. Т.е., что бы была связка, например:
EmployeeVO(1, Vasia) -> Employee(34, Vasia)
5. Наконец, используя подобные маппинги внутренних идентификаторов на иднтификаторы, полученные из БД, вы производите все необходимые действия.

Да бредос полный. Даже писать ответ не хочется - до того все криво. Нельзя менять айдишники в БД, на то он и ID. Нельзя менять айдишники в Хибере, так как вы рискуете порушить кеш первого уровня, в недрах которого хранится сопоставление айдишников и соответствующей сущности. Это все от лукавого.
Нужны VO со своими айдишниками и соответствующие им ентити со сгенерированными айдишниками. В противном случае получается полный трешак.

slipperyPetro123slippery,
там есть scope идентичности объектов в пределах сессии.
Хибер гарантирует, что по АДРЕСУ 2 объекта одинаковы так-же, как и по ID в СУБД.
В СУБД нету адресов.
Влезать в это механизм - оверхед.
да я и не хочу влезать, просто мне сказали что можно сделать так чтоб не произошла генерация ИД, в остальном то верно же, разве нет. Какая разница, ну дерну я секвенц отдельным запросом, то что база отдаст вставлю как ИД объекта и сохраню. помоему нормальная схема, не вижу ничего в ней нарушающего. Если только знать как можно отключить этот @GeneratedValue для сущности в рантаймеСкорее всего можно заэкстендиться от какого-нибудь класса и переопределить поведение генератора. Погуглите по словам "hibernate GeneratedValue turn off".