Как предотвратить параллелизм в веб-сервисе API?
Вы попытались установить UpdateSourceTrigger на PropertyChanged? С другой стороны, Вы могли назвать UpdateSOurce () методом, но это походит на небольшое излишество и побеждает цель привязки данных TwoWay.
5 ответов
Предполагая, что нельзя просто заставлять веб-сервер иметь только один прослушивающий поток, обслуживающий запросы ... Я полагаю, я бы просто использовал статическую блокировку ( ReentrantLock вероятно , для ясности, хотя на самом деле вы можете синхронизировать любой общий объект):
public class Global {
public static final Lock webLock = new ReentrantLock();
}
public class ClassA {
public void go() {
Global.webLock.lock()
try {
// do A stuff
} finally {
Global.webLock.unlock()
}
}
}
public class ClassB {
public void go() {
Global.webLock.lock()
try {
// do B stuff
} finally {
Global.webLock.unlock()
}
}
}
public class ClassC {
public void go() {
Global.webLock.lock()
try {
// do C stuff
} finally {
Global.webLock.unlock()
}
}
}
Во-первых, не зная своей архитектуры, вы, вероятно, столкнетесь с проблемами, если вам придется принудительно применять ограничения параллелизма на уровнях WebService. Хотя вы можете использовать традиционные блокировки и т. Д. Для сериализации запросов через обе службы, что произойдет, когда вы добавите второй веб-уровень для масштабирования вашего решения? Если блокировки являются локальными для веб-уровня, они будут почти бесполезными.
Я предполагаю, что, вероятно, существует какой-то уровень, который находится под веб-службами, и именно здесь вам нужно обеспечить соблюдение этих ограничений. Если клиент B входит после того, как клиент A сделал конфликтующий запрос, то серверная часть должна отклонить запрос, когда обнаружит, что состояние изменилось, и затем вы должны вернуть 409 второму клиенту.
Ваш дизайн ошибочен. Услуги должны быть идемпотентными. Если классы, которые у вас есть, не поддерживают это, изменяйте их дизайн, пока они не появятся. Похоже, каждый из трех методов должен быть основой для служб, а не классов.
Вы можете использовать какой-то семафор для сохранения последовательного доступа к сервисам.
Почему бы не использовать гипермедиа для ограничения доступа?
Используйте что-то вроде,
POST /A
, чтобы запустить первый процесс. Когда он будет завершен, в результатах должна быть указана ссылка для запуска второго процесса,
<ResultsOfProcessA>
<Status>Complete</Status>
<ProcessB href="/B"/>
</ResultsOfProcessA>
Перейдите по ссылке, чтобы запустить второй процесс,
POST /B
и повторите для части C.
Возможно, плохо работающий клиент может кэшировать ссылку на шаг B и попытайтесь повторно использовать ее в будущем запросе, чтобы обойти последовательность. Однако было бы нетрудно назначить какой-либо токен при выполнении шага A и потребовать, чтобы токен передавался на шаги B и C, чтобы предотвратить создание клиентом URL вручную.
Читая ваши комментарии дальше, кажется, что у вас есть ситуация, когда A может быть запущен до или после B. В этом случае я бы предложил создать ресурс D, который представляет статус всего набора процессов (A, B и C). Когда клиент извлекает D, ему предоставляются URI, по которым ему разрешено следовать. После того, как клиент инициировал процесс A, ресурс D должен удалить ссылку B на время обработки. Обратное должно произойти, когда B инициируется раньше A.
Другое преимущество этого метода состоит в том, что очевидно, выполнялись ли A или B в течение дня, поскольку статус может отображаться в D. После того, как A и B были выполнены запустить, то D может содержать ссылку на C.
Гипермедиа не является 100% надежным решением, потому что у вас может быть два клиента с одной и той же копией D, и оба могут подумать, что процесс A не был запущен, и оба могут попытаться запустить его одновременно. Эту проблему можно решить, установив "