從SOAP/WS-API更新/寫入調用中分離GUI的好方法？

Question

假設我們有一些配置GUI，它以當前形式使用直接DB事務以一致的方式爲多個可配置組件提交新配置。

現在讓我們把數據（DB）的東西移到一些SOAP/WS API的後面。 GUI不再有直接的數據庫訪問。交易行爲必須保持，但API應該設計爲明確地適應GUI表單提交。事實上，我甚至不知道新的GUI將如何工作，或者用戶輸入的結構如何。因此我需要在API服務器端提供類似WS-AtomicTransaction的東西。但是，（至少）有兩個注意事項：

• GUI是用PHP編寫的：我不認爲在PHP中有任何WS-Transaction支持可用。
• 我不想在等待其他客戶端請求的同時在服務器端打開數據庫事務。

解決方案，我能想到的：

• 使用Camel's aggregation。但是，這會使事情至少在兩個方面變得更加複雜：
  • 您不能在同一事務中的後續調用中使用新插入行的DB行ID。您需要使用某種符號後向引用，因爲在處理聚合消息時客戶端和服務器之間不會進行通信。
  • 呼叫回復不會立即發生（或者對每個單個呼叫的直接和單獨回覆只會是某種存根，即不包含超出「您的信息已附加到TX xyz」的任何有用信息 - if這在駱駝聚合情況下是完全可能的）。
• 先前解決方案的兩個缺點讓我想到了請求批處理，其中WS標準提供了在批處理事務內部後續調用中引用調用結果的方法。有沒有這樣的東西可用？甚至可能作爲一個PHP客戶端？
• 嘗試通過謹慎使用行級鎖等來消除數據庫中的鎖爭用。但是，當插入新元素時，我的猜測是通常頁和索引頁需要由數據庫鎖定。
• 也許一些服務器端持久層使用樂觀鎖？但是，如果數據庫寫入將被推遲到提交（不知道這是否可能），那麼在最終提交之前，這不會將任何DB ID返回給客戶端。

什麼你想？

Answer 1

交易是一個強大的工具，我們很容易進入一個思維模式，在這個模式中，我們將每個問題看作是用這把大錘擊中的釘子。我可以與你的困惑聯繫起來，因爲我親身體驗過它。不幸的是，我沒有更好的建議，比嘗試不考慮交易而是原子API調用。

當我想到在交易方面，我的思維模式通常是這樣的：

• 開始交易
• 讀取（請根據需要重複）
• 更新（根據需要重複）
• 承諾/回滾

需要一些時間才能認識到我們過度使用這種模式。實際的衝突是很少見的，還有很多其他的處理方式。這裏是一個常用的中的API

• 讀取和發送數據到客戶端（原子API調用）
• 更新數據（客戶端）
• 送原裝+更新回到服務器（原子API調用）
  • 開始交易（在服務器上）
  • 閱讀
  • 與原來比較來自客戶端
  • 如果不一樣，返回錯誤（CL ient應重試）
  • 如果相同，更新
  • 提交

最後六個點的API調用的實現的一部分。

費倫茨·米哈伊 http://theamiableapi.com