問題タブ [transactions]

この夏、私は基本的な ASP.NET/SQL Server CRUD アプリを開発していましたが、単体テストは要件の 1 つでした。データベースに対してテストしようとしたときに、問題が発生しました。私の理解では、単体テストは次のようにする必要があります。

• ステートレス
• 互いに独立
• 同じ結果で繰り返し可能、つまり永続的な変更がない

これらの要件は、データベース用に開発する場合、互いに矛盾しているように見えます。たとえば、挿入する行がまだそこにないことを確認せずに Insert() をテストすることはできないため、最初に Delete() を呼び出す必要があります。しかし、それらがまだそこにない場合はどうなりますか? 次に、まず Exists() 関数を呼び出す必要があります。

私の最終的な解決策には、非常に大きなセットアップ関数 (ヤッ!) と、最初に実行され、セットアップが問題なく実行されたことを示す空のテスト ケースが含まれていました。これは、テストのステートレス性を維持しながら、テストの独立性を犠牲にしています。

私が見つけた別の解決策は、 Roy Osherove の XtUnit のように、簡単にロールバックできるトランザクションで関数呼び出しをラップすることです。これは機能しますが、別のライブラリ、別の依存関係が含まれており、目前の問題に対する解決策としては少し重すぎるようです。

では、この状況に直面したとき、SO コミュニティは何をしたのでしょうか?

tgmdbm は次のように述べています。

通常、お気に入りの自動単体テスト フレームワークを使用して統合テストを実行します。そのため、混乱する人もいますが、同じルールに従っているわけではありません。多くのクラスの具体的な実装を含めることができます (それらは単体テストされているため)。具象クラスが相互に、およびデータベースとどのように相互作用するかをテストしています。

したがって、これを正しく読んだ場合、データ アクセス層を効果的に単体テストする方法は実際にはありません。または、データ アクセス レイヤーの「単体テスト」には、データベースとの実際のやり取りとは関係なく、クラスによって生成された SQL/コマンドなどのテストが含まれますか?

私はしばらく前にいくつかのテストを行いましたが、これを機能させる方法がわかりませんでした。

材料：

• COM +トランザクションオブジェクト（VB6で開発）
• 
  COM+コンポーネントを呼び出すIISの.NetWebアプリケーション（トランザクションあり）は
  、SQLデータベースの行を更新します

テスト：

.Netアプリケーションを実行し、例外を強制します。

結果：

.Netアプリケーションから行われた更新はロールバックされます。
COM+オブジェクトによって行われた更新はロールバックされません。

古いASPページからCOM+オブジェクトを呼び出すと、ロールバックが機能します。

「なに？！COM +や.Netは気にしないでね！」と思っている方もいらっしゃるかもしれませんが、この世界にはまだCOM+のコンポーネントがたくさんあるところがあります。誰かがこれに直面したことがあるかどうか、そしてあなたがこれを機能させる方法を理解したかどうか、私はただ興味がありました。

COM +または.NETトランザクションをサポートしない外部APIを使用して「トランザクション」プロセスを作成する必要があります（正確にはSharepoint）

私がする必要があるのは、シーケンスでいくつかのプロセスを実行できるようにすることですが、そのシーケンスで障害が発生すると、前のすべてのステップを手動で元に戻す必要があります。私の場合、ステップは2種類しかなく、どちらも元に戻す/ロールバックするのはかなり簡単です。

これに役立つ可能性のあるデザインパターンや構造についての提案はありますか？

データベーストランザクションにどの程度依存していますか？

小さなトランザクションスコープと大きなトランザクションスコープのどちらが好きですか？

サーバー側のトランザクションよりもクライアント側のトランザクション処理（.NETのTransactionScopeなど）を優先しますか、またはその逆ですか？

ネストされたトランザクションはどうですか？

取引に関するヒントやコツはありますか？

トランザクションでの作業で遭遇した落とし穴はありますか？

あらゆる種類の回答を歓迎します。

SQL Server 2000 クエリ アナライザで次のクエリを実行すると、次のようになります。

40 行が OurTable のスキーマに準拠しているが、最後の 20 行の形式が変更されているテキスト ファイル (最後の 20 行のフィールドが少ないとします) では、エラーが発生します。ただし、最初の 40 行はテーブルにコミットされます。Bulk Insert を呼び出してトランザクションにならないようにする方法について何かありますか、または失敗時に強制的にロールバックするために明示的な何かを行う必要がありますか?

既存の C++ アプリケーションを、新しい Java ベースのシステムに徐々に置き換える予定です。Java ですべてを完全に再実装するまでは、C++ と Java が相互に通信する必要があると予想されます (RMI、SOAP、メッセージングなど - まだ決定していません)。

今、私のマネージャーは、同じ Oracle DB トランザクションに参加するには、Java 側と C++ 側が必要になると考えています。これは、DB やメッセージ キューなどの 2 つのトランザクション リソースを 1 つのプロセスで調整するという通常の分散トランザクションの問題と関連していますが、これとは異なります。

プロセス間でトランザクションを伝播することは、パフォーマンスと安定性の観点からはひどい考えだと思いますが、それでも解決策を求められます。

私は XA トランザクションに精通しており、JBoss Transaction Manager でいくつかの作業を行いましたが、2 つのプロセス間で XA トランザクションを伝播するのに良い結果が得られませんでした。

Java 側で Spring を使用していますが、Spring のドキュメントには、Spring はトランザクションの伝播を支援しないと明示的に記載されています。

従来の Java EE サーバー (IBM Websphere など) を使用する予定はありません。これは、伝播をサポートしている可能性があります (決定的なドキュメントを見つけることができるわけではありません)。

解決策に関するヘルプやポインタは大歓迎です。

私の作品には、複数のユーザーが同時に作業できる でVB.NET書かれた金融アプリケーションがあります。SQL

ある時点で、1 人のユーザーが、自分 (および場合によっては他のユーザー) が現在取り組んでいるエントリのバッチを投稿することを決定する場合があります。

明らかに、Post プロセスが開始された後、他のユーザーがそのバッチのエントリを追加、編集、または削除することは望ましくありません。

Post プロセスが開始された瞬間に SQL トランザクションを開くことですべてのデータをロックできることは既に確認しましたが、プロセスはかなり長くなる可能性があり、関数を完了するのに数分間かかる可能性があるため、トランザクションを開いたままにしないでください。 .

VB.NET コードから操作する必要があるとわかっているレコードだけをロックする方法はありますか?

SQL トランザクション ログを表示/クエリするための優れたツールを使用したことがある方がいらっしゃいましたら、お知らせください。これにより、コミットまたはロールバックされたすべてのトランザクション SQL ステートメントが表示されます。

データベース ファイルの場合、インデックスの内部バイナリ ツリー構造を表示するような追加のグラフィカル機能があれば、それは素晴らしいことですが、私はあまりにも多くのことを求めていると思います..

通常の ACID トランザクションがどのように機能するか、あいまいな方法で理解しています。ある種のコミットフラグが設定されるまで作業が確認されないように、データベースでいくつかの作業を実行します。コミット部分は、いくつかの基本的な仮定に基づいています (単一のディスク ブロックの書き込みがアトミックであるなど)。壊滅的なエラーが発生した場合は、リカバリ フェーズでコミットされていないデータを消去できます。

分散トランザクションはどのように機能しますか? MS のドキュメントのいくつかで、データベースとファイルシステム間で何らかの方法でトランザクションを実行できることを読みました (とりわけ)。

このテクノロジーは、プログラムを完全にインストールするか、完全に存在させないようにするインストーラーに使用できます (おそらく使用されています)。インストーラーの開始時にトランザクションを開始するだけです。次に、レジストリとファイルシステムに接続して、インストールを定義する変更を行います。ジョブが完了したら、単純にコミットするか、何らかの理由でインストールが失敗した場合はロールバックします。レジストリとファイル システムは、この魔法の分散トランザクション コーディネーターによって自動的にクリーンアップされます。

2 つの異なるシステムがこのように処理される可能性はありますか? ファイルシステムが変更をコミットし、レジストリがコミットしていないという、一貫性のない状態でシステムを放置することは常に可能であるように私には思えます。MSDTC では、ネットワークを介してトランザクションを実行することさえ可能だと思います。

http://blogs.msdn.com/florinlazar/archive/2004/03/04/84199.aspxを読みましたが、説明の冒頭に過ぎず、手順 4 を大幅に拡張する必要があるように感じます。

編集: http://en.wikipedia.org/wiki/Distributed_transactionで収集したものから、2 フェーズ コミット ( http://en.wikipedia.org/wiki/Two-phase_commit )によって実現できます。これを読んだ後でも、私はまだこの方法を 100% 理解していません。ステップ間にエラーの余地がたくさんあるようです。

私は現在、ユーザーがそのテーブルの1つのスキーマの一部を指定できるようにするレガシーシステムを更新しています。ユーザーは、このインターフェースを介してテーブルの列を作成および削除できます。このレガシーシステムはADO2.8を使用しており、データベースとしてSQL Server 2005を使用しています（この獣を近代化する試みが始まる前に、どのデータベースを使用していたかを知りたくありません...しかし、私は逸脱します。=））

この同じ編集プロセスで、ユーザーは、これらのユーザー作成フィールドに格納できる有効な値のリストを定義（および変更）できます（ユーザーがフィールドに入力できる値を制限したい場合）。

ユーザーがフィールドの有効なエントリのリストを変更したときに、有効な値の1つを削除すると、新しい「有効な値」を選択して、この（現在は無効な）値を含む行をマップできます。それらは再び有効な値を持ちます。

古いコードを調べてみると、上記の変更はトランザクション内で行われないため、システムが無効な状態になることに対して非常に脆弱であることがわかりました（したがって、他の誰かが上記のプロセスの途中でやって来て、独自の変更...まあ、あなたは引き起こすかもしれない問題を想像することができます）。

問題は、単一のトランザクションでそれらを更新しようとしていることですが、コードがそのテーブルのスキーマを変更する部分に到達するたびに、他のすべての変更（行の値の更新、スキーマが変更されたかどうかに関係なく、トランザクションのその時点までに作成されたテーブルは完全に無関係なテーブルである可能性があります）サイレントにドロップされているように見えます。ドロップされたことを示すエラーメッセージは表示されず、最後にトランザクションをコミットしてもエラーは発生しません...しかし、トランザクションで更新されるはずのテーブルを調べると、新しい列のみが表示されますある。行われたスキーマ以外の変更は保存されません。

ネットで答えを探すのは、これまでのところ、数時間の無駄であることがわかっています...そこで私は助けを求めてここに向かいます。テーブルのスキーマを更新し、テーブル内の行を更新する（同じテーブルであろうと他のテーブルであろうと）ADOを介してトランザクションを実行しようとした人はいますか？許可されていませんか？この状況で役立つ可能性のあるドキュメントはありますか？

編集：

さて、私はトレースを行い、これらのコマンドはデータベースに送信されました（括弧内の説明）

（ここで何が起こっているのかわかりません。一時的なストアドプロシージャを作成しているようです...？）

（ユーザーが生成したフィールドの定義情報を保持するテーブルを取得します）

（私のコードは、現在の情報を取得して、ここでそれらのリストを繰り返し処理していたと思います）

（これは、定義の変更されたデータを入力している場所のようです。それぞれを調べて、カスタムフィールド自体の定義で発生した変更を更新します）

（これは、この保存が始まる前に、私のコードがインターフェースを介して削除されたものを削除する場所です] ...これは、このトランザクション中に実際に発生することを私が知る限り、唯一のことでもあります）

（ユーザーが作成した列のプロパティを変更したり、列のインデックスを追加/削除したりする必要があるように定義のいずれかが変更された場合は、ここで行われ、任意の行にデフォルト値が与えられます指定された列の値はまだありません...私が知る限り、ストアドプロシージャが終了したときに、これは実際には発生しないことに注意してください。）

（トランザクションを閉じる...？）

上記のすべての作業の後、列の削除のみが発生します。トランザクション内の前後のすべてが無視されているように見え、トランザクション中に問題が発生したことを示すメッセージがSQLトレースにありませんでした。