Каков наилучший шаблон дизайна для предотвращения дублирования представлений? - PullRequest
4 голосов
/ 17 октября 2010

У меня есть шаблон проектирования, с которым я боролся о том, как лучше всего предотвратить повторное размещение данных.

Вот шаги:

  1. Клиент отправляет данные с уникальным guid (сгенерированный клиентом guid - гарантированно уникальный)
  2. Программное обеспечение на стороне сервера гарантирует, что guid клиента еще не существует в БД
  3. начинается транзакция
  4. обработка данных (может занять от 1 до 20 секунд в зависимости от полезной нагрузки)
  5. совершает транзакцию

Вот сценарии: Клиент отправляет данные с guid «1», а затем повторно отправляет данные с guid «1» до того, как на шаг (5) выполняется исходная отправка данных, затем транзакция обрабатывается дважды.

Каков наилучший шаблон проектирования для предотвращения этого без использования семафоров или блокировок? Пользователь должен иметь возможность повторить отправку, если по какой-либо причине первая отправка не удалась (проблема с оборудованием на стороне сервера и т. Д.).

Спасибо!

Ответы [ 5 ]

1 голос
/ 17 октября 2010

Сохранение GUID в столбце с ограничением SQL UNIQUE.

Когда вы пытаетесь (в рамках транзакции) вставить второй дубликат GUID, операция завершится неудачей, после чего вы откатите всю транзакцию.

1 голос
/ 17 октября 2010

Вы можете реализовать шаг 2, используя запрос, который считывает незафиксированные данные. Например, если вы используете MS SQL Server, вы можете сделать это:

IF NOT EXIST(SELECT * FROM SomeTable (NOLOCK) WHERE Guid = @ClienGUID)
BEGIN
   -- Insert the GUID ASAP in the transaction so that the next query will read it
   -- Do steps 3-5
END

Ключ здесь - подсказка (NOLOCK), которая считывает незафиксированные данные

0 голосов
/ 06 ноября 2017

Создайте таблицу running_transactions, в которой вы храните GUID транзакций, которые выполняются в настоящее время, т.е.

  1. Сохранить GUID в running_transactions.
  2. Программное обеспечение на стороне сервера проверяет в этой таблице, существует ли GUID или нет, если да, то ответом является «транзакция в процессе».
  3. Программное обеспечение на стороне сервера проверяет в БД дубликаты GUID. Если существует, ответ «дублирующая транзакция».
  4. Если успех от 2 и 3, тогда начните транзакцию и завершите ее. В течение этого времени, если запросы снова приходят с тем же GUID, прежде чем произойдет комит, он будет перехвачен на шаге 2. 5.После завершения транзакции удалите GUID из таблицы running_transactions.

Примечание. Этот подход работает только в том случае, если эта таблица остается светлой (не более 1 записей), а выбор и удаление выполняется быстро. Также вы можете индексировать столбец GUID.

0 голосов
/ 17 октября 2010

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

0 голосов
/ 17 октября 2010

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...