Озверина почему тут работать не будет? Я думал проблемы с onetoone ?ну OneToOne - известная грабля, решается обещанием что запись есть при помощи optional=false, однако, lazy в ManyToOne/OneToOne с натуральным ключем при наличии суррогатного не умеет, ну просто потому что в сессии сущности только по одному ключу доступны: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/EntityType.java#L461

Озверина потом меня спрашивают, почему я могу предпочесть запросы сущностям со связями.Ну это только одна из проблем, а там их горы, вот примеры:

захотел в старом хибере чтобы он мне Stream возвращал вместо списка, начал смотреть как реализовали в новом: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/query/internal/ScrollableResultsIterator.java - збс, в итераторе вызов hasNext() курсор двигает сколько угодно раз

захотели блокировки в нужных местах делать, вроде паттерн стандартный: блокируем запись по id, потом обновляем сущность из БД, а вот нельзя так если в сущности есть @Version-поле - это поделие зачем-то в запрос условие на штамп версии вставляет: https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/dialect/lock/PessimisticWriteSelectLockingStrategy.java#L111

ну и в общем так постоянно: чуть в сторону от элементарных вещей и сразу грабли на ровном месте.

ПылинкаЗачем блокировать пессимистически, если там автоматом оптимистическая блокировка встроена?не автоматом, а костылем. Оптимистичная блокировка полезна в довольно ограниченных случаях, а именно когда пользователь пытается сохранить строку, а мы его отшиваем и говорим: тут пока ты думал что-то поменялось, иди и разбирайся сам что произошло, в остальных случаях пользы от нее никакой: ну на кой черт нам что-то обрабатывать, а потом в коммите словить ошибку, что не получилось? мы же наверняка знаем что будем менять, поэтому на порядок проще заблокировать то что нужно, а потом уже обновлять. С хиберовским же подходом, получается так, что он пуляет кривой select for update в базу, не получает результата и кидает StaleObjectStateException, от которого толку вообще никакого нет, вот что с ним делать? Ловить в цикле пока не пропадет? а как понять что вообще случилось? Ситуация что строчки в базе нет может быть вызвана по крайней мере тремя причинами, нам еще каждую гипотезу проверять и тоже перехватывать исключения? Вот на ровном месте получается куча стремного кода.

забыл никЗачем тогда вообще использовать Version?Без @Version пользаки будут данные друг друга тихо перетирать, если вы предлагаете вместо @Version пилить что-то свое, то это опять же будет камень в сторону хибера.

забыл никНо пессимистичная используется когда высокий шанс коллизии, а если такой шанс есть, то имеет смысл использовать пессимистик-лок ВСЕГДА, как-то у меня картина не сходится. Это не в укор, хоть я и повидал много бизнес-доменов, но такое вижу впервые, поэтому и интересно узнать в каких случаях такое бывает.Ну сначала вы придумали уловное разделение на пессимистичные/оптимистичные и всегда/невсегда, а теперь пытаетесь заставить меня обосновать такое разделение, ну давайте попробуем.

разделение на всегда/невсегда неверное, просто потому что при записи (обновлении) в базу блокировка возникает всегда и длится от момента когда мы захватили строку до коммита/отката транзакции, правильно здесь делить на явные/неявные. Поэтому если мы на 100% уверены, что вот в этом определенном месте мы будем писать в базу (к примеру от пользователя пришел запрос на обновление), какого-либо смысла не ставить блокировку нет - она так или иначе возникнет, вопрос здесь только в том когда она возникнет, и вот здесь уже начинаются нюансы, а именно:
- база позволяет "подсмотреть" заблокирована строка, которую мы собираемся обновлять или нет, соответственно если мы пытаемся поставить блокировку сразу, то у нас есть возможность указать сколько времени вообще ждать, чтобы не обламывать нашего любимого пользователя, а "сразу" сказать что ждать тут нечего
- если мы явные блокировки там где нужно не ставим, то начинаем ловить лулзы уже из-за неявных (там всякие автофлаши и пр.) - и здесь уже никаких таймаутов нет, и соломку не подложить

разделение на пессимистичные/оптимистичные вообще какое-то кривое, потому что из названия суть непонятна - просто так повелось, основная задача в "оптимистичных" - это производить обновления данных в базе актуальным вектором изменений, мы просто маркируем изменения штампом версии и перед тем как обновить сравниваем что там в базе, а блокировки здесь вообще никакой нет, более того, что мешает после подобной оптимистичной проверки заблокировать строку, чтобы больше никто не влез? ничего не мешает и противоречия/конфликта/пр здесь никакого я не вижу, более того, сам подход следовало бы назвать не "оптимистичным", а "наивным", ну вот что толку от того, что из 10 записей мы обновили 9, а на десятой обломались, потому что кто-то другой влез? мы во-первых, свою задачу не выполнили, во-вторых еще кого-то заблокировали.