在兩個連接之間共享事務空間

有一個應用程序可以在SQL Server 2008上啓動事務並移動一些數據。然後，雖然交易仍未提交，但應用會打印出一些標籤。在打印成功之前，事務不會被提交是非常重要的;如果發生打印錯誤，則會回滾所有內容。在兩個連接之間共享事務空間

現在，印刷引擎是a）變得相當龐大和複雜，並且b）最終需要很多地方。因此決定分離發動機並使其成爲服務。

是的，可以將打印所需的所有數據從客戶端應用程序傳遞到該服務器，以便服務器僅打印並且不關心數據庫。但是，這意味着在需要打印的每個應用程序中留下一堆代碼和標籤模板;有效地，然後將發生非常少的分離。相反，這將是extreemely高效（我寫和維護更容易）只傳遞所需的服務，然後將數據庫和獲取數據的ID。所有格式和佈局將集中，應用程序將只從打印作業12345請求5個送貨單。

現在，這不會發生，因爲交易在打印時尚未提交。該服務將無法讀取數據，並使用READ UNCOMMITTED不是一種選擇。

我打算使用舊的sp_bindsession來加入兩個會話，即應用程序和服務，但之後它突然被棄用並從未來版本中刪除。幫助建議我使用MARS或分佈式交易，但我看不出他們會如何提供幫助。

有什麼建議嗎？

來源

2010-01-12 GSerg

我的直覺是，試圖以這種方式共享兩個進程之間的事務並不是一個好主意。

我的方法是將所有數據傳遞給服務，或調查在打印期間保持事務處於打開狀態的替代方法 - 是否會有更簡單的機制（例如每個記錄的IsPrinted標誌）不夠？

如果做不到這一點，我可以看到這樣做的最佳方式是讓打印服務將其所有SQL請求傳遞迴原始進程，以便它們可以在原始事務的上下文中執行。

來源

2010-01-12 16:58:54 Justin

Rigth。經過一些雖然，我們決定不使用任何depecated功能已決定由印刷服務全局定義的每個標籤格式將有一個相應的存儲的SQL函數將返回帶有給定printjob的標籤參數的XML，調用者應用程序將在其上下文中執行該函數，並將所得到的XML作爲字符串傳遞給打印服務，這基本上是您的建議，但有點整理。 – GSerg 2010-01-13 10:25:33

只有sp_getbindtoken/sp_bindsession可以完成您所要求的操作，並且已被棄用並將被刪除。

理論上，您應該使用短交易，將'打印'狀態表示爲承諾狀態，並在打印失敗時進行補償。此外，如果打印引擎作爲服務公開，它應該是自治的，並且接收它需要打印的所有數據（如標籤模板）。我明白這對我來說很容易，但可能是該產品的一項主要工作。

現在我認爲你最好的選擇是使用會話綁定標記。儘管如此，我必須大聲宣佈，在物理操作（打印）期間開放交易是非常糟糕的做法。

來源

2010-01-12 16:44:06

問題是，不同的應用程序想要使用相同的標籤，並且目前每個應用程序都有自己的副本，這是不好的，因爲當佈局變化時我必須去更新每個應用程序。打印基本上沒有時間，因爲它是用打印機語言完成的，而不是GDI。打印機立即吃掉數據，之後即可完成工作。我寧願不做一個願意承諾，因爲其他程序然後會覺得自己可以根據最近的提交做出進一步的決定，現在我們來到一個我不太願意的自定義鎖定系統。因此，sp_bindsession，我想：（ – GSerg 2010-01-12 16:59:11

在兩個連接之間共享事務空間

回答

相關問題