2

Hibernate 3 を Hibernate 4 にアップグレードした後、Spring ベースのアプリから HibernateTemplate を削除せざるを得なくなりました。Hibernate セッションを利用できるようにするには、以前よりも一貫性のあるトランザクション境界を使用する必要があります。これには、トランザクション アドバイスをサービス レイヤーに追加するだけでなく、読み取り専用のデータベース操作を実行するバックグラウンド スレッドに細心の注意を払う必要があります。

私は 2 つのデータ ソースを持っています (2 つの異なるデータベースを使用する必要があります)。1 つ目はほぼすべてのアプリケーション リクエストに使用され、2 つ目は特別な (たとえば 1000 のうちの 1 つ) リクエストにのみ使用されます。最も簡単なのは、アスペクトを使用して、両方のデータベースのトランザクションで両方のリクエスト タイプをラップすることです (どのリクエストがどのデータベースを必要とするかを判断する必要はありません) が、これに伴うオーバーヘッドについて疑問に思っています。実際のデータベース接続の取得とトランザクション ロジック (コミットなど) は、実際のクエリが実行されるまで延期されますか? または、私のアプローチでは、多くの (実際には使用されていない) トランザクションが開始およびコミットされますか?

明確にするために、2 つのデータ ソース、2 つのトランザクション マネージャー、2 つの (同一の) "inServiceLayer" ポイントカットに対する 2 つのトランザクション アドバイスがあります。

助けてくれてありがとう！

4

2 に答える 2

1

そもそもオーバーヘッドを考慮していません。ここでわかる最大の問題は、あなたのアプローチに根本的な欠陥があることです。いくつかのロジックが DB-1 と DB-2 にアクセスでき、DB-1 でコミットした後、DB-2 にコミットしようとしたときに問題が発生し、DB-2 への txn をロールする必要があるとします。戻ると、DB-1 のトランザクションが既にコミットされているため、DB-1 と DB-2 のデータに一貫性がなくなります。

あなたの場合は、分散トランザクションをより適切に利用する必要があります (両方の DB が XA をサポートしていることを願っています)。そのため、Spring ポイントカットで処理する (分散) トランザクションは 1 つだけです。そして、(確信はありませんが) 通常の XA トランザクションでは、すべてのリソースで基礎となるトランザクションをやみくもに作成することはないと思います (つまり、基礎となる txn は必要な場合にのみ作成されます)。

したがって、分散 txn を使用すると、より正確で、具体的で、保守しやすく、(おそらく) リソースの浪費が少ない実装が得られます。

関連するセットアップでコンテナをさらに調べます。

于 2013-02-18T02:12:15.927 に答える
1

「アスペクトを使用して両方のリクエストタイプをトランザクションでラップする」とはどういう意味ですか? あなたの質問は、アプリケーションが適切に階層化されていないことを示唆しています。@Transactionalトランザクション ロジックが宣言的に ( ) またはプログラム的に ( )適用される、ある種のデータ アクセス レイヤーが必要TransactionTemplateです。これは、データベースにヒットしないリクエストがトランザクションを開くことは決してないことを意味します。

編集:
適切な階層化がオプションでない場合、トランザクション処理のオーバーヘッドが確実に発生します。Spring のトランザクション境界の標準ツールは、この種の「レイジー/オンデマンド」トランザクション初期化を実装していません。これを証明する最も簡単な方法は、使用しているトランザクション マネージャーでデバッグ/トレース レベルのログ記録を有効にすることです。

于 2013-02-17T17:42:33.497 に答える