シナリオ:Hi/LoはLo100で初期化されMyEntity
ます
テーブルは空です。
接続が異なる2つのセッションで、両方とも3つのアイテムが挿入されました。
TableIds
1
2
3
100
101
102
3つ目が後で入って、3つのアイテムを挿入した場合:
TableIds
...
200
201
202
これらのギャップを回避する方法はありますか?
シナリオ:Hi/LoはLo100で初期化されMyEntity
ます
テーブルは空です。
接続が異なる2つのセッションで、両方とも3つのアイテムが挿入されました。
TableIds
1
2
3
100
101
102
3つ目が後で入って、3つのアイテムを挿入した場合:
TableIds
...
200
201
202
これらのギャップを回避する方法はありますか?
Lo 値は、Session ではなく、SessionFactory に対して保存されます。アプリケーションを再起動して SessionFactory の新しいインスタンスを作成する場合にのみ、ギャップが発生します。
新しい Hi 値がデータベースから取得され、SessionFactory に格納されるため、Web ファームがある場合、各サイトには、データベースから独自の「次の」Hi 値を持つ SessionFactory の独自のインスタンスがあります。Lo 値がなくなると、Hi をデータベースから次に利用可能な Hi に更新します。
編集:
クライアント アプリケーションがある場合は、HiLo をまったく使用せず、代わりに GuidComb を使用することをお勧めします。これはシーケンシャル Guid であり、ギャップの問題はありません。
ただし、これは既存のアプリであり、実際に識別子を変更することはできないため、独自の SF を持つ Web サービスを介して挿入するようにクライアント アプリケーションを要求することをお勧めします。これにより、クライアントごとに複数の Hi ではなく単一の Hi を維持できます。アプリ。
それができない場合は、ローを下げる必要があります。
Phill
非常に正しく指摘されているように、たとえばアプリケーションの再起動などを構築したり、クラウド上で実行していて、各ノードに独自の と のセットがある場合に、ギャップが発生sessionFactory
しHi
ますlo
。
ギャップを減らすの 10
ではなく、lo を減らすことができます。また、安心のために使用することをお勧めします。100
int64
int32
しかし、ギャップは実際に重要ですか?自分が不足しているのを見たことがありますか?
使用時に多数のギャップがあるパフォーマンス (データベースの問題) について否定的なものを読んだことはありませんHilo
。私が見た唯一のことは、使用中int32
またはlo
高に設定されているときに不足していると不平を言う人がいるということです.