Вам понадобится эта традиционная обработка исключений, несмотря ни на что, поскольку, как вы указали, всегда есть вероятность, что между вашей последней проверкой и фактическим запросом произойдет сбой. Поэтому я действительно думаю, что любое решение, которое вы найдете, должно попытаться плавно взаимодействовать с этим.
Вы не указываете, должны ли эти нестабильные ресурсы взаимодействовать каким-либо скоординированным образом, что указывало бы на то, что вам, вероятно, следует использовать какой-либо менеджер транзакций для этого. Я не верю, что для большинства нужд вы хотите вникнуть в суть управления транзакциями в коде приложения.
Иногда я также видел, как люди используют AOP для инкапсуляции логики повторения в серверных системах, которые выходят из строя (например, из-за проблем с тайм-аутом). При экономном использовании это может быть достойным решением.
В некоторых случаях вы также можете использовать технологию очередей сообщений, чтобы уменьшить нестабильность серверной части. Например, вы можете зафиксировать очередь сообщений как часть транзакции и выскочить из очереди только в случае успеха. Но такой дизайн обычно возможен только тогда, когда вы можете жить с асинхронным процессом.
И, как всегда, реальная стабильность может быть достигнута только путем устранения основной причины проблемы. У меня была исправлена ошибка 25-летней давности в стеке TCP / IP мэйнфреймов, потому что мы ее переполняли, поэтому возможно .