有一个应用程序在SQL Server 2008上启动事务并移动一些数据。然后，在事务仍未提交的情况下，应用程序会打印出一些标签。非常重要的是，在打印成功之前不会提交事务;如果发生打印错误，则所有内容都会回滚。
现在，打印引擎是a）变得非常庞大和复杂，并且b）最终需要来自许多地方。因此决定将发动机分开并使其成为一项服务。
是的，可以将从客户端应用程序打印所需的所有数据传递到该服务器，以便服务器只打印并且不关心数据库。但是，这意味着在每个需要打印的应用程序中留下大量代码和标签模板;实际上，将会发生很少的分离。相反，只需将服务所需内容的ID传递给数据库并获取数据，就可以极其高效（并且更容易编写和维护）。所有格式和布局都将集中在一起，应用程序只会从打印作业12345中要求提供5份送货单。
现在，由于交易在打印时仍未提交，因此不会发生这种情况。该服务无法读取数据，使用READ UNCOMMITTED不是一个选择。
我打算使用好的旧sp_bindsession加入两个会话，应用程序和服务，但随后它会被突然弃用并从将来的版本中删除。帮助建议我使用MARS或分布式交易，但我看不出他们会如何帮助。
有什么建议吗？
答案 0 :(得分：0)
只有sp_getbindtoken / sp_bindsession可以执行您所要求的操作，并且不推荐使用它并将其删除。
理论上，您应该使用短交易，将“打印”状态表示为已提交状态，并在打印失败时进行补偿操作。此外，如果打印引擎作为服务公开，它应该是自主的并且作为消息接收它需要打印的所有数据（如标签模板）。我理解这对我来说很容易说，但可能是该产品的一项重大任务。
目前我认为最好的办法是使用会话绑定令牌。尽管如此，我必须要求在实际操作（打印）期间保持交易开放是一种非常糟糕的做法。
答案 1 :(得分：0)
我的直觉是，尝试以这种方式在两个进程之间共享事务并不是一个好主意。
我的方法是要么将所有数据传递给服务，要么研究在打印期间保持事务处于打开状态的替代方法 - 更简单的机制（例如每条记录的IsPrinted标志）是不够的？
如果不这样做，我能看到的最简单的方法是让打印服务将所有SQL请求传递回原始进程，以便它们可以在原始事务的上下文中执行。