Sql server 在两个连接之间共享事务空间

有一个应用程序可以在SQLServer2008上启动事务并移动一些数据。然后，当事务仍未提交时，应用程序打印出一些标签。在打印成功之前不提交事务是非常重要的；如果发生打印错误，所有内容都将回滚

现在，打印引擎a）变得相当庞大和复杂，b）最终需要从许多地方获得。因此，决定将发动机分离并进行维修

是的，可以将打印所需的所有数据从客户端应用程序传递到该服务器，以便服务器只打印，而不关心数据库。然而，这意味着在每个需要打印的应用程序中留下成堆的代码和标签模板；实际上，这样就不会发生什么分离。相反，只需将所需内容的ID传递给服务，然后服务就会进入数据库并获取数据，这将非常有效（并且对我来说更容易编写和维护）。所有格式和布局都将集中化，应用程序将只要求打印作业12345中的5份送货单

现在，这不会发生，因为在打印时事务仍然没有提交。该服务将无法读取数据，并且使用readuncommitted也不是一个很好的选择

我本来打算使用旧的

sp_bindsession

加入两个会话，应用程序和服务，但后来它突然被弃用，并从未来的版本中删除。帮助建议我改用MARS或分布式事务，但我看不出它们会有什么帮助

---

有什么建议吗？

只有sp_getbindtoken/sp_bindsession可以按您的要求执行，它已被弃用并将被删除

理论上，您应该使用短事务，将“打印”状态表示为提交状态，并在打印失败时进行补偿操作。此外，如果打印引擎作为服务公开，它应该是自治的，并作为消息接收它需要打印的所有数据（如标签模板）。我明白这对我来说很容易说，但可能是该产品的一项重大任务

---

目前，我认为您最好的选择是使用会话绑定令牌。尽管我不得不指出，在物理操作（打印）期间让事务保持打开状态是一种非常糟糕的做法。

我的直觉是，试图以这种方式在两个进程之间共享事务不是一个好主意

我的方法是要么将所有数据传递给服务，要么研究在打印期间保持事务打开的替代方案——简单的机制（例如每个记录的IsPrinted标志）是否不够

---

如果做不到这一点，我能看到的最有效的方法就是让打印服务将其所有SQL请求传递回原始进程，以便它们可以在原始事务的上下文中执行。

关键是，不同的应用程序想要使用相同的标签，目前每个应用程序都有自己的副本，这是不好的，因为当布局发生变化时，我必须去更新每个应用程序。打印基本上不需要时间，因为它是用打印机语言完成的，而不是GDI。打印机在作业完成后的任何时间内都会读取数据。我不想做一个可能的提交，因为其他程序可以根据最近的提交自由地做出进一步的决定，现在我们来定制一个锁定系统，我很不愿意这么做。因此，我想sp_bindsession：（.Rigth.经过深思熟虑后，我们决定不使用任何不相关的功能。我们决定，打印服务全局定义的每个标签格式将有一个相应的存储sql函数，该函数将返回带有给定打印作业标签参数的XML。调用方应用程序将在其上下文中执行该函数，并传递生成的XML作为打印服务的字符串。它基本上是您建议的，但有点整理。