а как в EJB3.0 организована изоляция транзакций? Если сессия 1 пишет в запись X в базе данных, но не делает пока commit, а сессия 2 читает эту же запись X, то получит сессия 2 старую версию X, которая была до того, как ее изменила сессия 1? Или сессия 2 получит исключение, что запись недоступна?

funikovyuriа как в EJB3.0 организована изоляция транзакций? Если сессия 1 пишет в запись X в базе данных, но не делает пока commit, а сессия 2 читает эту же запись X, то получит сессия 2 старую версию X, которая была до того, как ее изменила сессия 1? Или сессия 2 получит исключение, что запись недоступна?

EJB3 поддерживает как пессимистическую, так и оптимистическую стратегии реализации транзакций. В первом случае прочитанные данные блокируются в БД на период действия транзакции, во втором только в момент фиксации (т.е. commit'а), при этом согласованность достигается с помощью использования специального атрибута отвечающего за хранение текущей версии записи (обычно это timestamp атрибут)

Все работает точно так же как и в самой БД так как все операции с persistence-capable объектами рано или поздно транслируются в SQL (в том числе операции управления транзакциями). Таким образом если вы в сессии 1 открыли транзакции то она, грубо говоря, открылась и в БД. Отличия в основном касаются расширенным возможностям по кэшированию данных на клиенте. Т.е. если вы выбрали оптимистичную стратегию, открыли транзакцию, а затем создали и сохранили 10 объектов то с точки зрения БД ничего еще не произошло, так как пока все это находится на клиенте. Зато как только вы выполнили commit для этой сессии в БД будет открыта транзакция, затем выполнены 10*n sql операций, требуемых для сохранения этих объектов и выдана sql команда commit. Т.е. все делается умно и по-закону...

вопрос был не о блокировках, а об уровне изоляций транзакций (transaction isolation level). Описанная модель блокировок нужна в том случае, когда сессия 2 пытается ИЗМЕНИТЬ ту же самую запись, которую уже поменяла сессия 1. В данном случае сессия 2 хочет просто прочитать запись, уже измененную в базе, но не зафиксированную. Выглядит это так:

Сессия 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 заблокирована?

funikovyuri NN-123

как я упоминал - все взаимодействие с БД все равно будет на SQL... так что если вы открыли транзакцию в repeatable read то и в СУБД будет открыта транзакция с таким же уровнем изоляции... стратегии о которых я говорил будут влиять на момент когда эта транзакция будет реально открыта.

Т.е. например, при оптимистической блокировке:

1-я сессия прочитала объект
1-я сессия его изменила

2-я сессия прочитала его с TIL = repeatable read **



т.е. сессия 2 получит значение не из кэша EJB, а сделает новый SELECT к базе и получит старое значение "123"?

funikovyuri
в случае пессимистической блокировки вторая сессия бы просто ждала commit'а первой на шаге (**)

Т.е. не смотря на то, что вторая сессия хочет только читать, она все равно будет заблокирована? Т.е. операция чтения тоже блокируется? Но база данных не блокирует операцию чтения. Во всяком случае Oracle точно не блокирует. Даже если запись X заблокирована сессией 1 (см. мой пример выше) в момент t1, то сессия 2 в момент t2 получит значение из базы и оно будет равно 123. Стало быть EJB будет тормозить операции чтения на ровном месте?

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.

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