一部のデータをRFIDカードに書き込み、一部のデータをデータベースに書き込みたいと仮定します。理論的には、データベースへの接続はいつでも切断される可能性があり、カードとカードリーダー間の接続もいつでも切断される可能性があります。あなたの目標は、両方が書かれるか、まったく書かれないかのどちらかになるような、ちょっとアトミックな方法でそれを設計することです。
これを解決するためのエレガントなアプローチはありますか？ヒントは大歓迎です:)
（違いが生じる場合に備えて、MS SQL ServerとWindowsスマートカードモジュール（Winscard.dll）を使用しています）
RFIDカードの更新を開始する前にレコードを挿入し、完了したらこのレコードを更新します。このようにして、半分完了した更新を見つけて、それに応じて行動することもできます。
次に、タイムアウト期間が経過した後に不完全なレコードを解決するプロセスを用意します（再試行するか、その他の方法で）。
RFIDカードと通信している間は、データベーストランザクションを開いたままにしないでください。次のようになります。
'やや'を定義します。真のアトミックな方法では、スマートカードモジュールが分散トランザクションに参加する必要があります。スマートカードAPIやプロバイダーがトランザクションをサポートしていることを私は知りません。
アトミックでないものはアトミックではないことを意味し、牛が帰宅するまで再試行とステータスのゲームをプレイできますが、スマートカードの書き込みがべき等でない限り、障害が発生した場合に正確になる可能性はありません。スマートカードの書き込みがべき等である場合は、再試行とackロジックの問題です。ステータスが「保留中」のDBに書き込み、コミットしてからスマートカードに書き込み、ステータスが「完了」のDBに書き込みます。クラッシュ時には、ステータス「保留中」をスキャンして再試行するプロセスが必要です。スマートカードの書き込みはべき等であるため、再試行は安全です。はい、ここではテーブルをキューとして使用することが重要です。
最初にデータベースを更新してから、データベースの更新が成功したことをRFID更新の述語にする必要があります。データベースの更新もトランザクションでラップして、アトミックにする必要があります。
もちろん、後続のRFID更新が失敗した場合は、データベース更新をロールバックする必要があります。したがって、データベースの更新にトランザクション監査を含めることを検討します。RFIDの更新が失敗した場合は、DBの更新に対してロールバックルーチンを呼び出すことにより、一貫性のある状態に戻ることができます。
お役に立てれば！