RFIDカードにいくつかのデータとデータベースにいくつかのデータを書き込むと仮定します。 理論上、データベースへの接続はいつでも中断する可能性があり、カードとカードリーダー間の接続はいつでも破損する可能性があります。 あなたの目標は、ちょっと原子的な方法でデザインすることです。幾分原子的な方法でデータベースとrfidカードに書き込むための優雅な解決策
これを解決する方法はありますか。 任意のヒントが理解されている:)
を（私は場合にはMS SQL ServerとWindowsスマートカードモジュール（Winscard.dll）を使用しています、それはどんな違いが）
あなたがあなたのアップデートを開始する前にレコードを挿入しますRFIDカードは、完了したらこのレコードを更新します。このようにして、半分の完了したアップデートを見つけ出し、それに応じて行動することもできます。
次に、タイムアウト時間が経過した後に（不断のレコードを解決するプロセスをもう一度試してください。
が、これは意志として、あなたはRFIDカードと通信しながら、データベーストランザクションを開いたまましようとしないでください：
データベースを更新してから、データベース更新が成功したときにRFIDアップデートを述語化するといいでしょう。データベースの更新は、それをアトミックにするためにトランザクションにラップする必要があります。
もちろん、後続のRFIDの更新が失敗した場合は、データベースの更新をロールバックする必要があります。したがって、データベースの更新を伴うトランザクション監査を含めることを検討します。 RFIDの更新に失敗した場合は、DB更新用のロールバックルーチンを呼び出して、一貫性のある状態に戻ることができます。
希望すると便利です。
'いくらか'を定義します。真のアトミックな方法では、スマートカードモジュールが分散トランザクションに参加する必要があり、スマートカードAPIやトランザクションをサポートするプロバイダは認識していません。
アトミックが少ないということは、アトミックではないことを意味し、牛が家に帰るまでリトライとステータスのゲームをプレイできます。スマートカードの書き込みがidempotentでない限り、障害が発生しても正しさはゼロになります。スマートカードの書き込みが冪等である場合、ステータスは「保留」、コミット、スマートカードに書き込んだ後、ステータスが「完了」のDBに書き込むことで、再試行と確認ロジックの問題になります。クラッシュ時にステータス「Pending」をスキャンして再試行するプロセスが必要です。スマートカードの書き込みは冪等であるため、再試行は安全です。はい、Using Tables as Queuesがここに関連します。
Java Cardと他の多くのスマートカードOSはトランザクションをサポートしています。しかし、私はあなたがそれをDB取引に参加していることを言及していると思います。それは別の種類の魚です。 –
トランザクションをサポートしている場合は、分散トランザクションにも登録できる必要があります。基本的には、[Open XA]（http://en.wikipedia.org/wiki/X/Open_XA）を実装するか、XA suportとのカードサポートトランザクションをブリッジするドライバを書くことができます。 –
「やや原子的」というものはありません。 2つの別々のレコードが書かれているか一緒になっていない場合は、トランザクションメカニズムが必要です。 –
「多少」とは、本当に原子的であることはおそらく不可能ではあるが、原子操作を可能な限り妥当かつ実現可能に似ていることを意味する。分散トランザクションは素晴らしく思えるかもしれませんが、余計な努力の価値はないでしょう。 – mibollma