問題タブ [acid]

これが私のシナリオです：トランザクションを完了する前に、異なるWCFサービスに対して3つまたは4つの呼び出しを行う必要があります-もしあれば、私のオプションは何ですか？

1つの呼び出しが失敗すると、すべてが失敗します...これらのサービスは同じドメインにない場合があることに注意してください。

乾杯！

READ COMMITTED のデフォルトの分離レベルで同時ユーザーが実行した場合、次のトランザクションで何が問題になる可能性がありますか?

ACID準拠のNoSQLデータ ストアはありますか?

特定のアクションをアトミックに実行したいアプリケーションがあります。ただし、これらのアクションはリモート ストレージで発生しており、接続が切断されたり、アクションが失敗したりする可能性があります。

ACID プロパティを強制する方法に関する文献はたくさんあります (先行書き込みログ、ARIES など)。しかし、これらの一般的な実装はありますか?

基本的に私が探しているのは、いくつかのライブラリ/API/などです。ここで、ログ用に安定したストレージ (ローカル ハードディスクなど) を提供し、特定のアクションを (不安定なリモート ストレージで) 実行し、この架空のヘルパー コードで ACID ブックキーピングの大部分を処理することができます。

明らかに、特定のものをロールバックする独自のカスタムコードを提供する必要がありますが、ログの実行、ログのスキャンなどの高レベルを一般化して、いくつかのライブラリにラップできるようです。

そのようなものは存在しますか？

Microsoft がAcid 3 テストで IE9 を 100/100 で合格させる計画があるかどうか知っている人はいますか? IE9 の現在のバージョンは、テストで 68/100 を取得します (ここで表示できます。メイン サイトはこちら)。

IE8は何を通過しましたか? IE7はどうですか？Safari、Firefox、Chrome などの他の最新のブラウザーと比べてどうですか?

次のコードを検討してください。

このシナリオでは、SQLInstaller.exe によって行われた変更はロールバックされますか? 具体的には、Process.Start() を通じて起動された外部プロセスによって行われた変更は、TxF によって処理されますか?

ありがとう！

HBase FAQ で最初に読んだサンプル スキーマの 1 つは、多対多関係の Student-Course の例です。このスキーマには、Student テーブルに Courses 列があり、Course テーブルに Students 列があります。

しかし、HBase でこれら 2 つのオブジェクト間の整合性を保証する方法がわかりません。あるテーブルを更新する前に何かがクラッシュした場合、問題が発生します。

トランザクション機能があるようですが、すべてのプットでこれを使用するコストはいくらですか? または、問題について考える他の方法はありますか？

MySql InnoDB は自動コミットをオフに設定し、デフォルトの分離レベル REPEATABLE READ を使用します。2 つの異なるトランザクション T1 と T2 が時系列で実行されるシナリオが 2 つあります。

1)

T1 は、T2 がまだ解放していない行 2 の書き込みロックを取得できないため、t3 でタイムアウト エラーを取得します。ただし、T1 が t4 でコミットすると、T1 の「部分的な」更新につながります。つまり、行 1 は更新されますが、行2 そうではないため、ACID の「原子性」規則は、この慣行によって違反されます。

ACID の「原子性」ルールによれば、トランザクションは「完了する」か失敗する必要がありますが、部分的ではありません。

APP は、T1 にロールバックを要求するか、t3 でエラーを受信して​​ t4 でコミットする前に、成功するまでタイムアウトした更新を再試行する必要があります。これにより、アトミシティ ルールが達成されます。

2)

1) DB はタイムアウト エラーを APP に配信するだけであり、T1 をロールバックするかどうかを決定するのは APP 次第ですが、2) DB はデッドロック エラーを検出するだけでなく、デッドロックになる可能性のある T2 をロールバックするように動作します。

理論的には、1) DB は T1 をロールバックするように動作することもできますが、2) DB はデッドロックを引き起こす操作をキャンセルしてデッドロック エラーを APP に送信するだけで、T2 をロールバックするかどうかを決定するのは APP 次第です。

問題は、最初に DB レベルでエラーが検出されたときに、APP またはそれ自体がロールバックを処理する必要があるかどうかを選択するために、DB がどの具体的な条件に一致するかということです。

どうもありがとう！

私はこれらから始めます - IMO素晴らしい - 記事：

• Base: An Acid Alternative - ダン・プリチェット著 (eBay)、2008
• 最終的に一貫した (- 再訪) - Werner Vogels (Amazon)、2008 年
• Brewer の予想と、一貫性があり、利用可能で、分割耐性のある Web サービス(非フリー) の実現可能性 - Seth Gilbert、Nancy Lnych (MIT)、2002 年

ACID が必要なスケーラビリティ/可用性を提供できなくなった (あるいは、ACID が極端な場合でも提供できる) 分散システムに関する記事にもっと興味があります。

記事は実用的な側面に焦点を当てる必要があります (私は数学が好きですが)。

私が特に興味深いと思うことの 1 つは、ACID 以外のアーキテクチャから派生できる経験則/設計パターン/... はどれですか?

私は、世界中のATMシステムがどのように設計されているかを悩ませています。銀行が世界中で一貫したシステムを設計することはかなり難しいに違いありません。これに結果整合性を使用しますか、それとも優れたACIDシステムを使用しますか？

私はある日スウェーデンにいて、銀行があり、ATMを使用し、飛行機で米国またはタイに行き、数時間後に海外でATMを使用することができます。システムに一貫性がある場合は、世界中のどこにでも非常に信頼性の高い接続が必要です。