deepsky NN-123
.....
Сессия 1 на клиенте в момент t1 открывает транзакцию, считывает запись X и меняет в ней значение в поле A с 123 на 456, после этого делает UPDATE. Но COMMIT сессия 1 не делает, потому что в этой транзакции должны быть изменены и другие записи в базе. COMMIT будет выдан потом, когда изменены будут все нужные записи.

В момент t2 (t2 > t1) сессия 2 считывает значение из поля A в записи X. Так как новое значение 456 в базе еще не зафиксировано, то актуальным является значение 123. Если вы сделаете SELECT с консоли базы данных, то непременно получите 123, а не 456.

В момент t3 (t3 > t2) сессия 1 делает commit.

Так вот вопрос: а что получит сессия 2 в момент t2 в архитектуре EJB3? 123, 456 или сообщение о том, что запись X заблокирована?

Получит примерно тоже что и в архитектуре 2.X . Синхронизация и взаимодействие конкурирющих транзакций определяются базой данных с которой работает ejb контейнер. Хотя деплоер и может выбрать при диплойменте режим блокировки optimistic/pessimistic, все возможные коллизии разрешаются на этапе коммита транзакции.
Что касается вопроса:
-в случае optimistic сессия 2 получит 123,
-в случае pessimistic - сессия перейдет в режим ожидания снятия эксклюзивной блокировки сессии 1 на запись Х. В случае Оракла, select for update используется как способ создать эксклюзивной блокировку.

PS это справедливо для уровней изоляции >= READ_COMMITED

Вот этот момент с блокировкой и непонятен. Вторая сессия, как уже было подчеркнуто, только читает заблокированную запись. Если, в соответствии с описанным выше, EJB использует для управления изоляцией механизм базы данных, то в случае READ COMMITTED база сама найдет старую версию записи до того, как сессия 1 ее исправила и сессия 2 получит "старое" значение 123.

В любом случае - заблокирована запись или нет для базы роли не играет (Oracle, например, хранит старые версии записей в undo и для него это не проблема). Так что если EJB не имеет собственного механизма управления изоляцией, то мы получим 123. Но есть сильные сомнения. Я не большой специалист в EJB, но из того что читал (сам ничего не тестировал!) складывается впечатление, что EJB сама управляет изоляцией и если сессия 1 изменила запись, но не зафиксировала ее с помощью commit, то сессия 2 не сможет прочитать запись и будет ждать, пока сессия 1 освободит запись. Такое впечатление было от обычного EJB, поэтому встал вопрос а в EJB3 это тоже так?

deepsky NN-123
... складывается впечатление, что EJB сама управляет изоляцией и если сессия 1 изменила запись, но не зафиксировала ее с помощью commit, то сессия 2 не сможет прочитать запись и будет ждать, пока сессия 1 освободит запись. Такое впечатление было от обычного EJB, поэтому встал вопрос а в EJB3 это тоже так?

Уровень изоляции - это абстракция, которая описывается теми или иными типами блокировок. Поэтому я бы не стал говорить, что уровень изоляции управляет доступом к записи со стороны конкурирующих транзакций. То что реально управляет доступом - так это блокировка, в этом плане спека на ejb предлагает две стратегии.
Подход в управления доступом для конкурирующих транзакций для EJB3 от EJB2 ничем не отличается, принцип тот же самый, проверить легко, задаунлоадив спеку. Или вы говоря про обычные EJB, имели ввиду версию 1?

Так как в EJB я не силен (в отличие от управлениея транзакциями в базе ), то насчет версий не скажу. Читал статью (под рукой нет), где приводился пример поведения подобному описанному Вами. Т.е. в случае entity beans изменение объекта якобы ведет к тому, что другая сессия будет ждать, когда объект освободится, даже если другая сессия просто хочет прочитать значение в поле этого объекта. Хотелось понять правда это или нет.

Что касается изоляции, то к блокировкам она отношения не имеет. Запись может не иметь никакой блокировки и все равно механизм изоляции будет вынужден считать старую копию записи (READ CONSISTENCY). Это тот случай, когда наш SELECT очень долго работает и наталкивается на запись, которая была изменена другой транзакций, пока наш SELECT работал. Уровни изоляции определяют что получит операций чтения, если она встретит измененную запись. Блокировки тут не причем. Вторая сессия могла уже сделать commit и освободить запись.

EJB предлагает 2 модели блокировок для предотвращения перезаписи одной записи несколькими сессиями. Это т.н. оптимистическая (в конце) и пессимистическая (в начале) блокировки. К уровням изоляции они отношения не имеют. Или речь о каких-то других блокировках?

deepsky
NN-123
EJB предлагает 2 модели блокировок для предотвращения перезаписи одной записи несколькими сессиями. Это т.н. оптимистическая (в конце) и пессимистическая (в начале) блокировки. К уровням изоляции они отношения не имеют. Или речь о каких-то других блокировках?
Речь идет именно о них, и они тоже имеют отношения к уровням изоляции базы данных, особенно пессимистическая - поскольку в этом случае именно база данных синхронизирует выполнение параллельных транзакций, и конечно уровень изоляции, а если глубже копнуть, то и способ реализации изолированности - блокировки влияют на их выполнение. Выполняется это при вызове методов ejbLoad, ejbCreate, ejbStore - пункт 9.1.12 для спеки на EJB3. С оптимистичными блокировка - все сложнее и разнообразнее, здесь многое зависит от апп сервера.

наличие или отсутствие пессимистической блокировки НИКАК не влияет на работу механизма изоляции. Пессимистическая блокировка это не что иное как выдача SELECT FOR UPDATE. Запись блокируется во время SELECT и остается заблокированной до окончания транзакции. Никакой изоляции делать не надо, поскольку изменения нет. Изоляция начинается с того момента, когда сессия выдала UPDATE, DELETE, INSERT. В этот момент база данных должна где-то сохранить старую копию этой записи и тем самым обеспечить изоляцию. Oracle сохраняет старую запись в UNDO сегменте. Если какая-то другая транзакция сделает SELECT до окончания первой, то она получит старую версию записи из UNDO. Влияние на изоляцию оказывают только операции изменения, но никак ни SELECT. Есть у него FOR UPDATE или нет - это только SELECT, который ничего не меняет в записи базы данных.

P.S. Гуру Oracle скажут, что SELECT FOR UPDATE меняет запись и в UNDO при этом что-то попадет. Попадет. Признак блокировки записи, точнее неблокировки, т.к. старый вариант не был заблокирован. Но никакие "клиентские" данные не будут записаны в UNDO и параллельная транзакция будет брать значения в самой записи, а не в UNDO.

funikovyuri NN-123

Далее, for update это вообще всего лишь средство борьбы с deadlock'ами и к виду клиентской стратегии организации транзакций прямого отношения не имеет


for update это один из способов нарваться на deadlock. Чем больше for update, тем больше вероятность получить deadlock. Причина deadlock - эскалация блокировок. Если к обычным блокировкам, связанным с изменениями данных (и которых избежать невозможно), добавляются еще блокировки в момент SELECT (рукотворные блокировки, созданные по инициативе программиста), то общее число блокировок в базе возрастает. Это называется эскалация блокировок. Следствием этого может быть получение deadlock. Чем меньше блокировок, тем меньше вероятность deadlock.

Доказательств приводить не буду - откройте любую книжку где описано управление транзакциями.