«Пессимистическая автономная блокировка» с сторонними авторами соавторов

Question

У нас есть приложение, которое читает и записывает в стороннее хранилище данных. Код этого хранилища данных закрыт, мы не знаем об этом и не можем его изменить. Существует только тонкий API, который позволяет читать и писать.

pessimistic offline lock помогает охватить транзакции и работать с ними одновременно. Я верю, что это сработает.

Но теперь у нас есть проблема, что другое программное обеспечение также будет записывать и читать в это хранилище , и наше приложение должно обновляться, когда происходят изменения в этом хранилище данных. Само хранилище данных не предоставляет никаких уведомлений. Третье программное обеспечение не изменит какое-либо глобальное состояние, которое указывает, что что-то изменилось.

Есть ли какой-либо образец или наилучшая практика «наблюдать» за тем, чтобы хранилище данных и публиковать события для обновления всех клиентов (нашего программного обеспечения)?

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

Answer 1

Внесистемная реализация Пессимистичная автономная блокировка требует сотрудничества/участия/обеспечения соблюдения всех возможных модификаторов данных. Это, как правило, невозможно и является одной из двух причин, по которым этот подход редко применяется в современном программном обеспечении. Чтобы сделать что-либо дистанционно, подобное этому (то есть, с несколькими гетерогенными писателями) полезным способом, требуется какая-то помощь/помощь со стороны самих Системных средств. (Вторая причина - проблемы определения и разрешения заброшенных шлюзов, очень проблематичные).

Что касается возможных решений, то с чисто проектной точки зрения, либо оптимистичные автономные блокировки, которые по-прежнему нуждаются в некоторой помощи в системе, но и намного меньше, либо вообще избегают проблемы путем более подробного управления состояниями/управления в вашей модели данных.

Мой подход, однако, заключается в том, чтобы отложить вопрос проектирования (изначально), признав, что это прежде всего проблема возможностей хранилища данных и начинается там, ища использовать системный контроль блокировки/транзакции (которые как 1: обычно работают, так и 2: как это обычно делается).

AFAIK, вопросы синхронизации многопользовательский писатель всегда должен начинаться с «Какие инструменты/управления/услуги доступны для ограничения, отвлекают и/или отслеживать, не соответствующие приложения писателей?» Что вы можете сделать практически ограничены этими объектами.

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

На самом деле у меня нет прямого доступа к хранилищу данных, он размещен на некоторые сервера, и я не имею никакого контроля над другими приложениями, которые чтения и записи на него. Прямо сейчас, самое лучшее, о чем я могу думать, это иметь службу как прокси-сервер, который периодически запрашивает хранилище, сравнивает его с более старым состоянием и запускает события обновления моим клиентам, если какое-то другое приложение изменило его (и запустило другое если мое приложение изменяет его, чтобы уведомить моих собственных клиентов, оставив другим приложениям со своими проблемами).Это звучит не очень хорошо для меня, , но это, вероятно, делает эту работу.

Да, это все, что вы можете сделать, и это поддерживает только оптимистичную параллельность (частично), а не пессимистичную. Вы можете получить улучшения, добавив какую-то контрольную сумму/хэш в свои сохраненные данные, но это только оптимизация.