Блог

На моем сервере Apache Tomcat у меня есть OpenRDF Sesame triplestore для обработки троек 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», а другой клиент одновременно связывает ту же книгу с «John Doe», то может возникнуть ситуация, когда «John Doe» ссылается на книгу, которая больше не существует.

Чтобы попытаться найти решение, я совершил две транзакции. Первый из них (T1):

• (a) Проверьте, существует ли идентификатор книги (т.Е. «456789»).

• (б) Если да, свяжите данный профиль (т.Е. «JohnDoe») с этой книгой.

• (c) Если нет, верните ошибку.

Второй (T2):

• (d) Удалить книгу по идентификатору (т.Е. «456789»).

Проблема в том, что если последовательность равна (T1, a) (T2, d) (T1, b) (T1, c), снова возникают проблемы с согласованностью.

Мой вопрос: как обрабатывать блокировку (например, MySQL ДЛЯ UPDATE или GET_LOCK), чтобы правильно изолировать такие транзакции с помощью sesame?

Более старые версии Sesame (2.7.x и старше) не поддерживают изоляцию транзакций по HTTP. В HTTP-соединении транзакции просто выполняют пакетные операции вместе на стороне клиента, но с сервера блокировка не поступает, поэтому в этом сценарии нет способа контролировать изоляцию.

Таким образом, единственный способ справиться с этим в более старых версиях Sesame — быть надежным в своих запросах, а не полагаться на полную согласованность данных (что в любом случае является немного странной концепцией в парадигме бессхемных / полуструктурированных данных). Например, в этом конкретном случае убедитесь, что при запросе книг, связанных с профилем, данные книги действительно есть — не полагайтесь только на ссылку.

Однако в Sesame 2.8 и новее доступна полная поддержка изоляции транзакций по протоколу HTTP, а также доступен дополнительный контроль над точным уровнем изоляции транзакций для каждой транзакции. Схема блокировки зависит от конкретной реализации triplestore, которую вы используете.

Собственное хранилище Sesame использует оптимистичную блокировку, что означает, что оно предполагает, что транзакция сможет выполнить обновление, которое она хочет, и выдает исключение при возникновении конфликта. Установка уровня изоляции для транзакции определяет, как хранилище обрабатывает блокировку для одновременных транзакций. Руководство программистов Sesame содержит более подробную информацию об обработке транзакций и доступных уровнях изоляции. Уровень изоляции по умолчанию для транзакций в собственном хранилище равен SNAPSHOT_READ .

Что касается ваших примеров транзакций: на уровне изоляции по умолчанию T1 и T2 наблюдают согласованные моментальные снимки хранилища для своих запросов, и последовательность, в которой вы набрасываете ее, воспроизводится: T1 видит, что книга существует, таким образом добавляет ее в профиль, а T2 получает возможность ее удалить. Конечным результатом будет то, что профиль связан с несуществующей книгой — но на самом деле, технически это не является несоответствием, потому что T2 не выполняет никакой проверки того, используется ли конкретная книга в профиле или нет. Независимо от того, какой уровень изоляции транзакций вы используете, если в вашем сценарии T2 выполняется после T1, конечным результатом будет ссылка на несуществующую книгу. Если вы хотите убедиться, что не попадете в такую ситуацию, вам необходимо расширить T2, чтобы проверить, не связана ли удаляемая книга с профилем, и установить уровень изоляции SNAPSHOT или SERIALIZABLE .