2013-09-13 3 views
1

Я использую оптимистичную блокировку в приложении JPA2 (с использованием приложения EclipseLink v2.4) (без контейнера, только JavaSE). Я пытаюсь реализовать сильную согласованность, поэтому хочу, чтобы версии всех объектов, прочитанных во время транзакции, проверялись при фиксации.Проверка версий read set при фиксации в JPA 2 с оптимистичной блокировкой

Когда я использую MySQL как целевую БД, все происходит так, как я ожидаю: когда у меня есть клиент, выполняющий транзакции только для чтения одновременно с клиентом, выполняющим запись, некоторые транзакции только для чтения прерываются (и повторяются).

Однако, когда я использую HSQLDB (v2.2.9), транзакции только для чтения никогда не прерываются. Фактически, tcpdump ничего не показывает, что происходит через провод!

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

Чтение спецификации JPA сбивает с толку. Я даже гарантировал, что мои проверенные версии версий будут проверены, или только версии объектов, которые были изменены или удалены?

+0

Почему бы вам не предоставить нам немного кода? –

+0

Код - версия JPA [OO7 база данных] (http://pages.cs.wisc.edu/~dewitt/includes/benchmarking/oo7.pdf). Предполагается моделировать приложение САПР. Эти транзакции пересекают древовидный график «Ассембли» с листьями частей. Только транзакции только для чтения считывают детали, а транзакции записи изменяют поля частей. – Owen

ответ

0

HSQL - это база данных в памяти, которая, вероятно, имеет к ней какое-то отношение. Являются ли ваши клиенты в разных JVM? Вероятно, это не лучшая база данных для ваших нужд.

+0

Правда, но HSQL также позволяет удаленные подключения через TCP. Два клиента подключаются от отдельных JVM. Я выбрал HSQL, чтобы обработать SQL в БД в памяти. – Owen

1

Уровень изоляции может объяснить, почему некоторые вещи работают в MySql (например, если установлено значение Serializable), но, как вы сказали, оптимистическая блокировка не нуждается в этом (но, как сказано, может быть, это не оптимистическая блокировка, которая работает в MySql).

Я бы попытался обновить/понизить версию HSQLDB, чтобы быстро проверить, что она не является ОШИБКОЙ.

Кроме того, я полагаю, что вы проверили, что вы субъекты имеют поле с аннотацией @Version и что вы блокируете ЯВНО ПРИМИТИВ (пропускание LockModeType при вызове EntityManager.find(), обновление() или блокировки()), поскольку неясно, является ли/по умолчанию LockModeType (check this discussion).

Кроме того, если вы хотите отладить немного больше, вы можете посмотреть, какие запросы отправляются на HSQL (посмотрите here и here тоже посмотрите, как регистрировать запросы). В частности, я бы проверил, как обновлены/проверены обновленные поля @Version. Конечно, с отладчиком прилагается.

Конечно, без кода не так легко сказать, какие могут быть проблемы, но я полагаю, что это проблема в коде.

+0

Спасибо за предложения. Я посмотрел на SQL, отправленный на HSQL, и он только генерирует запросы типа UPDATE X SET Y = Z WHERE VERSION = W. То есть он генерирует SQL только для обновляемых объектов. Вы правы: я использую @Version для поля версии для каждого объекта. – Owen

+0

Я добавил несколько комментариев относительно LockModeType: вы явно блокируете объекты? –

+0

Я не блокирую сущности в обоих случаях.Я видел вопрос SO, на который вы ссылались, но я не вижу, как это приведет к тому, что конфигурация MySQL сгенерирует проверки версий, пропуская их для HSQL. Я начинаю задаваться вопросом, требуется ли явно блокировка объектов. В этом случае, что, ужасная абстракция. – Owen