Существует библиотека, которая реализует управление БД и может использоваться для реализации «бизнес-логики» приложения в отношении постоянства, где фактическим бэкендом является Apache Cassandra.Теперь, скажем, эта библиотека также взаимодействует с таблицами БД под капотом, прежде чем вернуть управление пользователю API.Одним из таких примеров будет выдача пакета облегченных транзакций (LWT) для некоторого раздела внутри, чтобы выполнить некоторые операции обслуживания таблиц, прежде чем пользователь API сможет начать взаимодействовать с разделом.Проблема возникает, когда пользователь API в течение небольшого промежутка времени после этого выдает не LWT-запросы, таким образом, время от времени попадая в ловушку, описанную в « Как выполнить легкие транзакции с линеаризованной согласованностью? ».
Например, библиотека выполняет вставки LWT, и после того, как управление возвращается пользователю API, он удаляет не LWT, а затем читает, что показывает, что строка, которая должна была быть удалена сейчас, фактически все еще там.Смешивание LWT и не LWT является хорошо известной проблемой согласно вышеупомянутой ссылке.Однако мне было интересно, есть ли, скажем, блокирующий запрос, который может быть выполнен клиентом, чтобы попросить серверную часть Apache Cassandra вернуть результат только для этого запроса, только когда результат (ы) Paxos связан с ранее запущеннымLWTs совершено ?Термин, который мне приходит в голову, чтобы лучше описать такой запрос одним словом, был бы " барьер ", который надежно изолирует секции (пакеты) LWT от секций (пакеты) не-LWT (и, если возможно, вообще), наоборот).
ПРИМЕЧАНИЕ: Очевидный и хакерский обходной путь, который работает в данный момент, - sleep(1) после внутреннего всплеска LWT.