ivanraКстати, а вот рояль в кустах. Чтобы получить значение автоинкремента без вставки записи, надо сначала её вставить, а затем откатить транзакцию.

А создатели oracle и firebird не знают. Там просто говоришь "дай мне следующее значение" и всё.
Собственно если ты решил дёргать БД для получения значения- прослойка в виде hibernate лишняя.

Кстати, надо понимать, что это (просить ID у БД) медлено .

ivanraAlexey Tomin, вопрос с использованием времени рассматривается. Но тоже дело в нюансах. Часть идентификаторов уже использована (исторические данные), так что надо попасть в определенный диапазон, чтобы не пересекалось, и в этом диапазоне занимать идентификаторы "плотно". Миллисекунды дают коллизии, а нано - слишком много занимают. Хотя, подогнать можно.

Если дыры допустимы, то не проблема при старте умножить ms на достаточно большое число (я тут подглядел- народ на 1000 умножает) а потом инкрементировать. Вряд ли вам больше 1000000 в секунду ID надо. Если на одной машине из разчёта 1М id в секунду, то хватит на 2^63/2^20 секунд, т.е. на ~280 тысяч лет. На наш век хватит
Можно даже построить систему из расчёта 10^9 id в секунду- хватит на 280 лет- тоже вряд ли доживём до претензий

Если дыры допустимы, но нежелательны, то можно в БД завести sequence, получать его SQL с инкрементом на некоторое число (1000, 1000000) - если приложение основилось, то мы потерям максимум столько ID.

Если дыры не допустимы вообще- то тут лучше всего ID получать каждый раз из БД. Но это узкое, очень узкое место.

Ну или красиво решение- создавать id с запасом и пихать в очередь сообщений (да хоть во временную таблицу), а кому надо- читают их.
Главное, чтобы кто-то говорил "хватит, довольно" вовремя