0

現在の形式で直接DBトランザクションを使用して、複数の構成可能なコンポーネントの新しい構成を一貫した方法で送信する構成GUIがあると仮定します。

それでは、データ（DB）をSOAP /WSAPIの背後に移動してみましょう。GUIには、DBに直接アクセスできなくなりました。トランザクションの動作はそのままにしておく必要がありますが、APIはGUIフォームの送信に明示的に対応するように設計しないでください。実際、新しいGUIがどのように機能するのか、ユーザー入力がどのように構造化されるのかさえわかりません。したがって、APIサーバー側でWS-AtomicTransactionのようなものを提供する必要があります。ただし、（少なくとも）2つの注意点があります。

  • GUIはPHPで書かれています。PHPで利用可能なWS-Transactionサポートはないと思います。
  • 追加のクライアント要求を待っている間、サーバー側でDBトランザクションを開いたままにしたくありません。

私が考えることができる解決策：

  • キャメルの集計を使用します。ただし、それは少なくとも2つの点で物事をより複雑にします。
    • 同じトランザクション内の後続の呼び出しで、新しく挿入された行のDB行IDを使用することはできません。集約されたメッセージの処理中にクライアントとサーバー間の通信が行われないため、ある種のシンボリック逆参照を使用する必要があります。
    • 呼び出しの応答は即時ではありません（または、各単一の呼び出しへの即時の個別の応答は、ある種のスタブにすぎません。つまり、「メッセージがTXxyzに添付されました」以外の有用な情報は含まれていません。キャメル集約の場合に可能）。
  • 前のソリューションの2つの欠点は、要求バッチについて考えさせます。WS標準では、バッチトランザクション内の後続の呼び出しで呼び出し結果を参照する手段が提供されている可能性があります。そのようなものはすでに利用可能ですか？たぶんPHPクライアントとしても？
  • 行レベルのロックなどを慎重に使用して、データベース内のロックの競合を排除しようとしています。ただし、新しい要素を挿入する場合、通常、ページとインデックスページはDBによってロックされる必要があると思います。
  • 楽観的ロックを使用しているサーバー側の永続層はありますか？ただし、DBの書き込みがコミットまで延期される場合は、最終的なコミットの前にDB IDがクライアントに返されることはありません（それが可能かどうかはわかりません）。

あなたはどう思いますか？

4

1 に答える 1

0

トランザクションは強力なツールであり、すべての問題をこの大きなハンマーで打つ釘と見なす思考パターンに簡単に陥ります。私は自分でそれを経験したので、あなたの混乱に関係することができます. 残念ながら、トランザクションではなく、アトミック API 呼び出しの観点から考えてみること以上に良いアドバイスはありません。

トランザクションの観点から考えるとき、私の思考パターンは通常次のようになります。

  • 取引開始
  • 読む（必要に応じて繰り返す）
  • 更新 (必要に応じて繰り返します)
  • コミット/ロールバック

このパターンを使いすぎていることに気付くには、少し時間がかかります。実際の競合はまれであり、それらに対処する方法は他にもたくさんあります。これは、API で一般的に使用されるものです。

  • データの読み取りとクライアントへの送信 (アトミック API 呼び出し)
  • データの更新 (クライアント上)
  • 元の + 更新をサーバーに送り返す (アトミック API 呼び出し)
    • トランザクションの開始 (サーバー上)
    • 読んだ
    • クライアントからのオリジナルと比較する
    • 同じでない場合は、エラーを返します (クライアントは再試行する必要があります)
    • 同じ場合、更新
    • 専念

最後の 6 つのポイントは、API 呼び出しの実装の一部です。

フェレンツ・ミハイ http://theamiableapi.com

于 2012-05-11T18:45:15.567 に答える