Я бы сначала посмотрел на то, почему вы хотите это сделать. Обычно приложения работают так, нет проблем в 2 клиентах, делающих вставки одновременно (ну, кроме неправильных подходов в коде).
Также решение будет зависеть от сценария. Одним из вариантов является наличие очереди сообщений Microsoft (MSMQ) и перемещение вставок из этих служб, поэтому загрузка вставок контролируется процессом, который читает из очереди.
Обновление 1: Я все еще не понимаю, почему вы хотите избежать параллельной работы вставок (и из того, что я прочитал в других ответах, я думаю, что другие делают). Я процитирую 2 ваших комментария по этому вопросу:
Причина, по которой я этого хочу, заключается в том, что в случае скачка напряжения я потерял только одну транзакцию вместо многих.
Муравей другой:
Это потому, что перед вставкой существуют другие длинные задания, требующие параллелизма. Только когда во время вставки требуется последовательный доступ.
Если бы я прочитал первый в одиночку, я бы на самом деле подумал, что это причина, по которой они нужны параллельно. Вы хотите покончить с ними как можно быстрее. Последовательное выполнение на самом деле увеличит время создания вставок, поэтому у вас будет больше времени, когда может произойти скачок напряжения.
Читая второе, я думаю, что вы, вероятно, больше обеспокоены влиянием этих процессов, выполняющихся параллельно, и вставкой, не попадающей в базу данных. Это снова означает, что вы хотите, чтобы вставки были выполнены как можно скорее, поэтому нет причин делать их последовательно.
Для встроенной поддержки у вас может быть случай для распределенной транзакции, которая также включает в себя файловую систему (ms смотрел на проблему файловой системы, но я не помню, делали ли они когда-нибудь что-нибудь на более новой ОС) , Распределенные транзакции, однако, довольно сложно настроить (msdtc и доступ к используемым портам).
Хороший путь, по которому я пошел, - это добавление дополнительной информации к процессу, чтобы можно было определить, где он вышел из строя. Вы можете даже не кодировать процесс автоматического восстановления, но по крайней мере вы знаете, что у вас будет информация, чтобы точно знать, что что-то пошло не так.
Самым простым способом является вставка в начале процесса и наличие флага, сигнализирующего о его завершении. Если это длительный процесс, вы можете захотеть иметь что-то более похожее на состояние, которое вы постоянно обновляете, чтобы иметь возможность определить, на каком этапе произошел сбой. Альтернативой является запись статуса в файловую систему.
В любом случае он будет сообщать вам только о том, что последний шаг завершился успешно, а не о том, был или нет текущий шаг завершен. Это то, что делает логику повторения более сложной, поскольку вы не можете просто продолжить с того места, где оно остановилось, вы должны проверить, был ли последний шаг выполнен или нет, и это зависит от каждого шага.
Ps. если это так, трудно понять из вопроса. Возможно, вы захотите открыть другой вопрос о длительных процессах и / или автоматических повторных попытках.