Совместное использование транзакционного пространства между двумя соединениями

Question

Есть приложение, которое запускает транзакцию на SQL Server 2008 и перемещает некоторые данные. Затем, пока транзакция еще не зафиксирована, приложение распечатывает некоторые метки. Очень важно, чтобы транзакция не была зафиксирована до тех пор, пока печать не будет выполнена успешно; если происходит ошибка печати, все откатывается.

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

Да, можно передать все данные, необходимые для печати, из клиентского приложения на этот сервер, чтобы сервер печатал только и не заботился о базах данных. Тем не менее, это будет означать, что в каждом приложении, которое требует печати, остаются груды кода и шаблоны этикеток; фактически тогда произойдет очень небольшое разделение. Напротив, было бы чрезвычайно эффективно (и мне было бы легче писать и поддерживать) просто передавать идентификаторы того, что требуется службе, которая затем направлялась бы в базу данных и получала данные. Все форматы и макеты будут централизованы, и приложения будут запрашивать только 5 накладных из задания на печать 12345.

Теперь этого не произойдет, поскольку транзакция еще не зафиксирована на момент печати. Служба не сможет прочитать данные, и использование READ UNCOMMITTED не совсем вариант.

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

Любой совет?

Answer 1

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

Мой подход состоял бы в том, чтобы либо передать все данные в службу, либо исследовать альтернативы хранению транзакции открытой на время печати - разве не будет достаточно более простого механизма (например, флага IsPrinted для каждой записи)?

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

Answer 2

Только sp_getbindtoken / sp_bindsession может делать то, что вы просите, и оно устарело и будет удалено.

Теоретически вы должны использовать короткие транзакции, представлять состояние «печати» как зафиксированное состояние и выполнять компенсационные действия в случае сбоя печати. Кроме того, если механизм печати представлен как услуга, он должен быть автономным и получать в качестве сообщения все данные, которые ему необходимо распечатать (например, шаблоны этикеток). Я понимаю, что мне легко это сказать, но это может быть серьезной задачей для продукта.

На данный момент я думаю, что вам лучше всего использовать токены привязки сессии. Хотя я должен сказать, что оставлять транзакции открытыми на время физических операций (печать) - очень плохая практика.