Обработка асинхронного сохранения с возможностью критических по времени ошибок? - PullRequest
0 голосов
/ 17 ноября 2011

Итак, чтобы объяснить это, я начну с просмотра стека приложений.

Система запускает JSP с jQuery сверху, общаясь через уровень контроллера с уровнем обслуживания, который, в свою очередь, использует уровень персистентности, реализованный в Hibernate.

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

Теперь у меня есть объект, который в любой момент времени может быть привязан только к одному контракту. В тот момент, когда я сохраняю контракт, я смотрю на все эти объекты и проверяю, охватывается ли они уже существующим контрактом. Однако, поскольку несколько клиентов могут экономить в любой момент времени, это создает риск преодоления проверки двух отдельных контрактов, что приводит к тому, что один объект привязывается к двум контрактам одновременно.

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

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

Моя первоначальная попытка состояла в том, чтобы сохранить поля данных для объекта, помещенного в очередь, а затем проверить их в ожидании блокировки, а затем выдать исключение или сообщить об успехе на основе того, что происходит. Это полностью заблокировало систему.

Кто-нибудь может указать мне правильное направление в отношении техник и схем, которые я должен использовать для этого?

Ответы [ 2 ]

2 голосов
/ 17 ноября 2011

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

  • Опрос потока, чтобы увидеть его состояние (не так хорошо).
  • Использовать какую-то систему обработки событий.У вас будет прослушиватель событий (возможно, OverlappingContractEventListener), а затем вы вызовете событие из потока, когда произойдет сценарий.Обработчику событий потребуется как-то сохранить эту информацию.

Если вы собираетесь использовать этот подход, то на стороне клиента вам нужно будет опросить.

  • Вы можетеопросите определенный контроллер (используя setInterval и AJAX), который ищет соответствующую информацию для объекта, чтобы увидеть, в каком состоянии он находится. Эта информация должна была сохраняться вашим прослушивателем событий.
  • Вы можете использовать веб-работников(это поддерживается в Chrome, Firefox, Safari и Opera. IE будет поддерживать его в 10) и выполнять опрос в фоновом режиме.

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

  • Выполнить AJAX-вызов контроллера.Контроллер будет ждать, пока служба вернет информацию.Код для отправки отзыва пользователю будет находиться в обработчике успеха вашего контроллера.
  • Используйте веб-работника для выполнения вызова в фоновом режиме.Веб-работник также будет выполнять вызов AJAX и ждать ответа.
1 голос
/ 17 ноября 2011

Разве вы не должны проверять дубликаты контрактов в базе данных? В зависимости от случая вы можете сделать это с помощью ограничения, триггера или хранимой процедуры. Если это не удается, отправьте исключение в стек. Это обычно способ справиться с такими вещами. Затем вы можете перехватить исключение в jQuery и отобразить ошибку:

Обработка ошибок jQuery Ajax, показ пользовательских сообщений об исключениях

Надеюсь, это поможет.

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