expp BlazkowiczЯ нигде не говорил про полный вынос локов в приложение. Я говорил что, вынося локи из базы, можно получать прирост производительности.

позволю себе небольшой пук ....

нужно просто разделять транзакции и локи уровня базы и уровня приложения. это совершенно разные понятия. разумеется можно реализовывать длинную транзакцию уровня приложения с помощью пессимистической блокировки FOR UPDATE.. но какой это сакс не мне вам рассказывать. гораздо эффективнее использовать оптимистическую "блокировку" с помощью колонок версий UPDATE ... WHERE verson=223 . но нужно понимать что работает это только потому что база обеспечивает READCOMMITED посредством своих лочек. т.е. когда мы флашим хибер сессию в кучу таких оптимистичных апдейтов. проапдейченные строчки блокируются - селекты других транзакций на них просто повисают. если один из апдейтов не проходит - версия поменялась т.е. имеем ноль проапдейченных строчек, получаем эксепшн и откатываем всё к чертям. тем самым имеем атомарный и целостный накат длинющей транзакции приложения очень дёшево и эффективно.

это мне кажется более точная формулировка "выноса локов..."

ну а организация таблички блокировок ("пессимизм своими руками") приводит к ботлнеку и куче висящих селектов. но имхо лучше for updateа

Как реагирует хибер когда мы закрыли сессиюь и открыли новою. но песемизм хотим реализовать на старой сесии(соответственно старой версии).

P.S.
Оптимизм своими ручками реализовать сложно. Напрактитике кто то так делал были ли траблы.
Скажем есть поле update_lock_time. Если оно null то устанавлеваем текущую дату. В ином случае оно залочено и ждем. Пока не разлочат.
Также проверка на timeout может залочили час назат и упал.
P.S.2 Терпеть не могу timeout-ы они гробят стабильность и производительность сетей IMHO.

Тьфу оптимизи. Когда использует версию.

expp Stub
Как реагирует хибер когда мы закрыли сессиюь и открыли новою. но песемизм хотим реализовать на старой сесии(соответственно старой версии).
желательно попроще мысли излагать...
Хибер не реагирует ни как. это не его собачье дело, при пессимистичном локе он выдаёт SELECT .. FOR UPDATE. дальше всё определяется поведением бд. (лочка висит до конца транзакции)

Stub
P.S.
Оптимизм своими ручками реализовать сложно. Напрактитике кто то так делал были ли траблы.
Скажем есть поле update_lock_time. Если оно null то устанавлеваем текущую дату. В ином случае оно залочено и ждем. Пока не разлочат.
хибер реализует оптимизм с помощью колонок версий (можно и таймстэмпами) вроде работает.
в этом наборе слов, кажется описан принцип реализации пессимистической блокировки своими руками

StubТакже проверка на timeout может залочили час назат и упал.
P.S.2 Терпеть не могу timeout-ы они гробят стабильность и производительность сетей IMHO.
но бывает как-то сказать что подумал, не стало мне ясно

Да иммено так. Сорри перепутал термины :-( .

Как хибер будет реагировать на версию(оптимизм) при закрытии сессии.
Если сессия закрыветься то и теряються персистентные обьекты с ихними версиями.