0

私はJPAのドキュメントを読んでいて、シーケンス id を割り当てているときに事前割り当てに遭遇しました。

明らかなパフォーマンス上の理由から非常に優れていますが。しかし、私は物事を台無しにするシナリオについて考えていました.

私が理解しているように、シーケンスを生成するための戦略としてテーブル シーケンスまたはシーケンス オブジェクトを使用するときに割り当てサイズ = 100 を設定すると、hibernate や Eclipse リンクなどの永続化プロバイダーはメモリ カウンターを維持し、レコードを挿入するためのアプリケーション コードはデータベースに移動する必要がなくなります。インサートごとに。

そのメモリカウンタが 100 に達すると、データベース シーケンスが 100 ずつインクリメントされ、同じストーリーが続きます。今まで大丈夫です。

しかし、本番環境でバグが発生し、一部のテーブルのレコードが DB に挿入されていないことがわかったとします。

そのため、これらのレコードを DB に挿入するスクリプトを準備します。ここで、テーブルの主キーに与える値を決定します。DB から値を取得すると、アプリケーションがレコードを挿入しようとしたときに競合する可能性が高くなります。メモリカウンターを使用すると、SQL 例外が発生します。

誰もそのような問題に直面しましたか? そして、そのような状況を処理する最善の方法は何ですか?

4

1 に答える 1

1

スクリプトで Hibernate ジェネレーターと同じ戦略を使用していることを確認してください。たとえば、シーケンスが 2300 にあり、Hibernate ジェネレーターがシーケンスを 100 ずつインクリメントし、シーケンスに移動せずに ID 2301 から 2400 を生成する場合、スクリプトで同じことを行います。

または、アプリケーションを停止し、スクリプトを実行して、Hibernate ジェネレーターが既に使用されている ID を生成しないことを保証する値でシーケンスを再生成します。

于 2012-09-25T11:07:34.277 に答える