Оптимистическая блокировка и блокировка полного стола

Question

У нас есть система, в которой мы время от времени получаем оптимистичное исключение блокировки. Мы работали над этим в коде, но теперь я смотрю JPA 2 и вижу, что для этого имеет аннотацию (@Version).
Проблема заключается в том, что более чем одна транзакция работает над таблицей, и с полной блокировкой таблицы это вызывает исключение оптимистической блокировки, даже если изменения не производятся в тех же записях.

Мы используем спящий режим на сервере JBoss 4.2, а база данных может быть либо MySQL, либо SQL Server.

Если бы мы изменили на использование @Version, это обеспечит блокировку строк в обеих базах данных или же мы можем ожидать оптимистичное исключение блокировки, вызванное полной блокировкой таблицы?

Edit:
То, что мы на самом деле видим, не оптимистическая блокировка ошибки, но тупиковый:

SQLServerException: Сделка была тупиковой на ресурсах блокировки с другой процесс и был выбран в качестве тупиковой жертва. Перезапустите транзакцию.

Мы имеем дело с этим в коде, но мне было интересно, может ли @Version оказать какую-либо помощь в этом случае.
По крайней мере, в одном из случаев этот тупик был вызван блокировкой стола, где два клиента работали с собственными данными.

Answer 1

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

Если у вас запущены SQL-запросы, для которых требуются блокировки таблиц, вам не удастся использовать поле версии. По умолчанию MS SQL Server использует блокировки строк. Вероятно, у вас есть небольшие таблицы или отсутствующие первичные ключи или есть другая причина, по которой SQL Server использует блокировки таблиц в вашем запросе.

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

Answer 2

Возможный дубликат: Optimistic vs. Pessimistic locking

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

Я шокирован тем, что вы получаете оптимистичные блокировки исключений без @Version, и в этом случае, возможно, вы получаете реальный RDBMS OCC error, но я в этом сомневаюсь. Скорее всего, происходит то, что весь объект будет отличаться от строки (поскольку вы не указали @Version), и в этом случае любые изменения в строке вызовут оптимистичное исключение блокировки. Пожалуйста, добавьте исключение в свой вопрос, поэтому я не должен его принимать.