а как в 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 будет тормозить операции чтения на ровном месте?