OpenRDF Sesame: как справиться с блокировкой?
На моем сервере Apache Tomcat у меня есть триплет-склад OpenRDF Sesame для обработки RDF-триплетов, связанных с пользователями и документами, а также двунаправленных связей между такими объектами:
http://local/id/doc/123456 myvocabulary:title "EU Economy"
http://local/id/doc/456789 myvocabulary:title "United States Economy"
http://local/id/user/JohnDoe myvocabulary:email "john@doe.com"
http://local/id/user/JohnDoe myvocabylary:hasWritten http://local/id/doc/123456
Это тройное утверждение, что пользователь Джон Доу с электронной почтой "john@doe.com" написал книгу "Экономика ЕС".
Приложение Java, работающее на нескольких клиентах, использовало такой сервер через HTTPRespository для вставки / обновления / удаления таких троек.
Проблемы возникают из-за одновременных подключений. Если Java-клиент удаляет книгу "456789" и другой клиент одновременно связывает одну и ту же книгу с "Джоном Доу", то может возникнуть ситуация, когда "Джон Доу" ссылается на книгу, которой больше не существует.
Чтобы попытаться найти решение, я совершил две транзакции. Первый из них (T1):
(a) Проверьте, существует ли идентификатор книги (например, "456789").
(b) Если да, свяжите данный профиль (например, "JohnDoe") с этой книгой.
(c) Если нет, верните ошибку.
Второй (Т2):
- (d) Удалить книгу по идентификатору (то есть "456789").
Проблема в том, что если последовательность (T1,a) (T2,d) (T1,b) (T1,c), снова возникают проблемы согласованности.
Мой вопрос: как обработать блокировку (например, MySQL FOR UPDATE или GET_LOCK), чтобы правильно изолировать такие транзакции с помощью сезама?
1 ответ
Старые версии Sesame (2.7.x и старше) не поддерживают изоляцию транзакций по HTTP. В HTTP-соединении транзакции просто группируют операции вместе на стороне клиента, но от сервера не получается блокировка, поэтому в этом сценарии нет способа контролировать изоляцию.
Таким образом, единственный способ справиться с этим в более старых версиях Sesame - это быть надежным в своих запросах, а не полагаться на полную согласованность данных (что в любом случае является немного странным понятием в парадигме данных без схемы / полуструктурированных данных). Например, в этом конкретном случае убедитесь, что при запросе книг, связанных с профилем, данные книги действительно есть, а не просто полагайтесь на ссылку.
В Sesame 2.8 и новее, однако, полная поддержка изоляции транзакций доступна через HTTP, а также предоставляется дополнительный контроль над точным уровнем изоляции транзакций для каждой транзакции. Схема блокировки зависит от конкретной используемой вами реализации хранилища триплетов.
Нативное хранилище "Сезам" использует оптимистическую блокировку, что означает, что оно предполагает, что транзакция может выполнить обновление, которое оно хочет, и выдает исключение при возникновении конфликта. Установка уровня изоляции для транзакции контролирует, как хранилище обрабатывает блокировку для параллельных транзакций. В руководстве программистов " Сезам" есть более подробная информация об обработке транзакций и доступных уровнях изоляции. Уровень изоляции по умолчанию для транзакций в собственном хранилище SNAPSHOT_READ,
Что касается ваших примерных транзакций: на уровне изоляции по умолчанию T1 и T2 оба наблюдают непротиворечивые моментальные снимки магазина для своих запросов, и последовательность, которую вы рисуете, разыгрывается: T1 видит, что книга существует, таким образом добавляет ее в профиль, и Т2 получает удалить его. Конечным результатом будет то, что профиль связан с несуществующей книгой - но на самом деле это технически не является несоответствием, потому что T2 не выполняет никакой проверки того, используется ли конкретная книга в профиле или нет. Независимо от того, какой уровень изоляции транзакции вы используете, если в вашем сценарии T2 выполняется после T1, конечным результатом будет ссылка на несуществующую книгу. Если вы хотите убедиться, что не можете попасть в эту ситуацию, вам нужно расширить T2, чтобы проверить, не связана ли книга, которую нужно удалить, с профилем, и установить уровень изоляции. SNAPSHOT или же SERIALIZABLE,