Хранимая процедура и блокировка запуска триггера

Question

У меня есть база данных SQL Server 2017 Express, к которой могут обращаться до 6 планшетов, которые подключаются через приложение Angular 7 с помощью веб-служб REST.

У меня есть хранимая процедура, позволяющая вставить нового пользователя вконкретная таблица базы данных. Вставка всегда будет вставлять только 1 запись за раз, но с 6 клиентами хранимая процедура может быть вызвана каждым клиентом почти одновременно.

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

С этим новым требованием,форма соглашения - это RTF-документ, который читается, значения заполнителей заменяются значениями из оператора вставки, записываются во временный файл и затем печатаются на сетевом принтере через приложение (скорее всего, Wordpad), которое связано с форматом файла RTF. .

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

У меня есть код C #, написанный для выполнения операции чтения / изменения / записи / печати формы, котораяиспользует свойство StartSfo UseShellExecute вместе с процессомМетод .Start.

Поскольку процесс чтения / изменения / записи / печати занимает несколько секунд, меня беспокоит наличие хранимой процедуры для добавления блокировки регистрации на этот промежуток времени.

Я почти уверен, что мне понадобится хранимая процедура CLR, чтобы клиент MS Access мог инициировать операцию печати, поэтому я выбрал либо хранимую процедуру Add_Registration (Transact-SQL)вызовите хранимую процедуру CLR для выполнения операции чтения / изменения / записи / печати или триггера вставки (CLR или Transact-SQL) в таблицу, которая вызывает хранимую процедуру CLR для чтения / изменения / записи / печати. ​​

Я мог бы избежать вызова от триггера к хранимой процедуре, дублируя код как в триггере CLR, так и в хранимой процедуре CLR, если для этого есть веская причина, но старался по возможности избежать дублирования кода.

Решения, которые я сейчас рассматриваю, заключаются в следующем, но я не уверен, как SQLСервер обрабатывает различные сценарии:

1. Триггер CLR или Transact-SQL Insert в таблице регистрации, который вызывает хранимую процедуру CLR, которая выполняет процесс чтения / изменения / записи / печати. ​​

2. Хранимая процедура CLR, которая выполняет процесс чтения / изменения / записи / печати, вызывается из текущей add_registration хранимой процедуры Transact-SQL

Вопросы, к которым я продолжаю возвращаться:

1. Как выполняются триггеры Insert CLR, если несколько вставок выполняются в одно и то же или почти в одно и то же время (только 1 на операцию)они поставлены в очередь, а затем обрабатываются синхронно или выполняются немедленно?

2. Тот же вопрос, что и в вопросе № 1, за исключением триггера Transact-SQL

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

4. Тот же вопрос, что и в # 3, за исключением хранимой процедуры Transact-SQL

5. Если хранимая процедура CLR вызывается из Transact-SQL триггер, блокируется ли триггер до тех пор, пока хранимая процедура не вернется, или вызов хранимой процедуры будет порожден ее собственным процессом (или аналогичным методом) с триггером, возвращаемым немедленно?

6. Тот же вопрос, что и в # 5, за исключением того, что триггер CLR вызывает хранимую процедуру CLR

Я ищу любые другие предложения и / или разъяснения о том, как SQL Server обрабатывает этисценарии.

Answer 1

Очередь не существует, если вы не реализуете ее самостоятельно, и есть несколько способов сделать это. Таким образом, для нескольких одновременных сеансов они все действуют независимо. Конечно, когда дело доходит до записи в БД (INSERT / UPDATE / DELETE / и т. Д.), Тогда они четко работают в том порядке, в котором они отправляют свои запросы.

Я неКонечно, почему вы включаете триггер во все это, но поскольку это относится к параллелизму, триггеры выполняются в сгенерированной системой транзакции, инициированной оператором DML, который сработал триггером. Это не означает, что у вас будут однопоточные INSERT, но если триггер вызывает хранимую процедуру SQLCLR, выполнение которой занимает секунду или две (а триггер не может продолжаться, пока хранимая процедура не завершится / не завершится), то возникают блокировкиудерживается на столе в течение всей этой операции. Эти блокировки могут не помешать одновременной вставке других сеансов, но у вас могут быть другие операции, пытающиеся изменить эту таблицу, требующие конфликтующей блокировки, которые должны будут ждать, пока не завершится операция proc insert + trigger + SQLCLR proc. Конечно, это может быть проблемой, только если у вас частые вставки, но это зависит от того, как часто вы ожидаете новых пользователей, и этого может быть недостаточно, чтобы беспокоиться.

---

Я тожене уверен, зачем тебе нужно что-то печатать в этот момент. На нескольких уровнях это может быть намного проще, если у вас просто есть столбец flag / BIT, указывающий, было ли напечатано соглашение, по умолчанию 0. Затем можно настроить внешнее консольное приложение, запланированное с помощью агента SQL Server или запланированных задач Windows, которое будет выполняться раз в несколько минут и которое будет считывать данные из таблицы Users WHERE HasPrintedAgreement = 0. Каждая строка имеет необходимые поля для значений замены, она печатает каждое и после печати обновляет значение UserID HasPrintedAgreement = 1. Вы даже можете запланировать выполнение этого консольного приложения раз в минуту, если вы всегда хотите, чтобы соглашения были немедленно.