Оптимистическая блокировка предотвращает блокировку в JPA?

Question

Я немного смущен преимуществами оптимистической блокировки в JPA.

Я проверил тест с двумя потоками и одной строкой на версии таблицы сущностей.
Вот что я нашел:

T1: begin tran 
T1: fetch single entity 
T1: Update field in entity 
T1: sleep 
T2: begin tran 
T2: fetch single entity 
T2: Update field in entity 
T2: commit trans 
T1: wake up 
T1: commit trans - throws OptimisticLockException (expected) 

Второй тест. Обратите внимание на добавление оператора select.

T1: begin tran 
T1: fetch single entity 
T1: Update field in entity 
T1: run select query on table (this causes a DB transaction to begin) 
T1: sleep 
T2: begin tran 
T2: fetch single entity (this blocks until DB transaction of thread T1 completes!) 
T2: Update field in entity 
T2: commit trans 
T1: wake up 
T1: commit trans - ok, no exception. The fetch/update/commit of T2 happened after T1 commit. 

Я действительно не ожидал какие-либо блокировок возникает при использовании оптимистической блокировки, однако я понимаю, что транзакция базы данных должна быть на месте здесь, так что правильные данные возвращаются из отборного заявления.
Поскольку JPA только кажется, что вводит транзакции базы данных, когда это абсолютно необходимо, может ли кто-нибудь объяснить, какие преимущества оптимистической блокировки?

Answer 1

В вашем первом примере вы правы, что JPA подвешивает обновления до тех пор, пока не будет абсолютно flush. Во втором примере он должен очистить их, чтобы выбор работал над актуальными данными.

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

Это означает, что вам потребуется реализовать обработку ошибок или повторить попытку. В случае, если вы не ожидаете каких-либо спорных обновлений, это может быть хорошо. В том случае, когда вы ожидаете, что многие клиенты будут одновременно обновлять одни и те же объекты JPA, может потребоваться достаточная логика приложения для обработки ошибок и разумно повторить обновление, не прибегая к ситуации с «последними комментариями».

Вы можете найти этот блог интересного https://blogs.oracle.com/carolmcdonald/entry/jpa_2_0_concurrency_and