問題タブ [acid]

できるだけ早く本番 SQL​​ Server 2005 サーバーに展開したいストアド プロシージャに、1 行のマイナーな変更 (文字列のタイプミスの修正) があります。

私が心配しているのは、正確な時間に変更ステートメントを実行してストアド プロシージャを更新するとどうなるかということです。何かが同時にそのストアド プロシージャを呼び出すことはありますか?

ストアド プロシージャの以前のコピーで実行されますか、それとも何らかの破損やエラーが発生する可能性がありますか?

SQL Server の ACID の性質を考えると、安全だと思います。特にSPが非常に小さいため、まったく同時に実行される可能性は非常に低いですが、私は確認することを好み、教育目的のためだけに答えにも興味があります.

おそらく、これには ServerFault の方が適しているでしょう。間違って投稿された場​​合は申し訳ありません。

ありがとうございました。

同時トランザクション間の共通レコードへの読み取り/書き込みアクセスの可視性レベルを制御するために、JDBC 接続でトランザクション分離レベルを設定できます。データベースがこれを実装する 1 つの方法は、レコード/テーブルにさまざまな種類のロックを配置することです。

しかし、データベースがこれらのトランザクション レベルを実装する他の方法はありますか?

1) データを保存し、2) データを処理する 2 つのサーバー側 HTTP エンドポイントを実装しました。メソッド 1) は、 App Engine タスクを介してメソッド 2) を呼び出します。これは、クライアントに待機させたくない時間のかかるタスクであるためです。このプロセスを以下のシーケンス図に示します。

ときどき、処理タスク (下のシーケンス図ではprocessSomethingthrow WtfException()という名前) が処理しようとしたときにデータを見つけられないことがあります (下の黄色で示されています)。これは、ここで説明されている結果整合性モデルで説明できますか?

ドキュメントには、読み取りには強力な一貫性がありますが、書き込みには最終的な一貫性があると書かれています。この事件に関連して、それが正確に何を意味するのかはわかりません。説明をいただければ幸いです。

編集:ここでブール値の質問をしていることに気づきましたが、最終的な整合性が一般的であり、具体的にはGoogleデータストアに関するドキュメントでバックアップされた回答を探していると思います

編集2：リクエストにより、実際の読み取り/書き込み操作の詳細は次のとおりです。

書き込み操作:

データの永続化に JPA を使用しています。オブジェクト「手」はクライアントから受信され、以前にデータベースに保存されていないため、新しいキーIdが割り当てられます。

読み取り操作:

主キーGameIdでもありません。RoundNoGameId は「外部キー」ですが、Datastore は設計上それを認識していません。

acid-store を使用して aeson Values を保存したいと思います。私は最小限の酸の実装を取り、単純に型を値に切り替えようとしました。これらは、deriveSafeCopy への私の呼び出しです。

JSONState と JSONStateStore は私自身の型です。次のエラーが表示されます。

編集問題は別のものだったので、この質問はもはや有効ではありません。私の答えの下にある私の説明を見てください。

エチケットがわからないので、この質問は現状のままにしておきます

テーブルにデータを書き込むストアド プロシージャがあります。

ストアド プロシージャの呼び出しに Microsoft Practices Enterprise ライブラリを使用しています。ExecuteNonQuery への呼び出しを使用して、ストアド プロシージャを呼び出します。

ExecuteNonQuery が返された後、サード パーティのライブラリを呼び出します。約 100 ミリ秒で別のスレッドでコールバックされます。

次に、別のストアド プロシージャを呼び出して、書き込んだばかりのデータを取得します。約 99% のケースで、データが返されます。時々、行が返されないことがあります (つまり、データが見つからない)。デバッガーでこの条件を検出する条件付きブレーク ポイントを配置し、ストアド プロシージャを手動で再実行すると、常にデータが返されます。

これは、書き込みストアドプロシージャが呼び出されたときにコミットしていないだけで機能していると信じさせます。

私はSQLに関してはかなり初心者なので、何か間違ったことをしている可能性は十分にあります。その内容がデータベースにコミットされるまで、ストアドプロシージャの書き込みがブロックされると思っていたでしょう。

ストアド プロシージャの記述

ストアド プロシージャの読み取り

銀行業務におけるデータの一貫性に関する記事を読んでいます。著者は、一般的な考え方とは異なり、銀行がサービスの高可用性を確保するためにBASE (基本的に利用可能、ソフト状態、最終的に整合性がある) トランザクションを採用しているという事実を強調しています。

簡単に言えば、迅速な対応を可能にするためにトランザクションは別のパーティションに書き留められ、データベースの整合性は後で実行されます。
たとえば、ATM からお金を引き出す場合、目的はできるだけ早くお金を受け取ることです。したがって、トランザクション操作は個別に保存され、お金が解放され、その後、トランザクションをデータベースに適用して一貫性を保つように注意が払われます。
これは、通信の技術的な制限によるものです。ACID (原子性、一貫性、分離、耐久性) トランザクションが使用された場合、応答性の高いサービスを提供することはできません。

もちろん、これは矛盾が生じる可能性があることを意味します。あなたが引き出す金額は利用可能な金額よりも多くなる可能性があり、取引が一貫する前に事前にそれを知る方法はありません. そして、ここで当座貸越ペナルティが発生します。これは、「過剰引き出し」に対して支払う手数料です。

問題は次のとおりです。銀行は、直面しなければならない制限が始まったときから気づいていたので、「過剰引き出し」トリックを導入したのでしょうか? 一種のハックのように技術的なコミュニケーションの問題を克服し、同時に可用性を提供するには? それとも、とにかく導入されたであろう「お金を稼ぐ」ための別の方法ですか？

この場合、両方のオプションが等しく価値があるように見えます。つまり、どちらも収益を大幅に高めることができます。