アプリケーションは、２つの異なる Session から同じ永続状態に同時にアクセスできます。しかし、２つの Session インスタンスが永続性クラスの１つのインスタンスを共有することはできません。ゆえに、識別子には２つの異なる概念があるということになります。

特定のSession に追加されたオブジェクトにとって （すなわち、１つの Session のスコープの中では） 、２つの概念は同じです。データベース同一性と JVM 同一性が一致することを、 Hibernate が保証します。しかし、アプリケーションが２つの異なるセッションから「同じ」（永続性識別子の）ビジネスオブジェクトに同時にアクセスする限り、２つのインスタンスは実際に（ JVM 識別子が）「異なり」ます。楽観的アプローチによって、 （自動バージョニングの） フラッシュ／コミット時にコンフリクトが解決されます。

このアプローチでは、 Hibernate とデータベースに同時実行についての心配が残ります。一方で、最高のスケーラビリティが提供されます。なぜなら、１スレッドの作業単位の中で一意性が保証されれば、高価なロックや同期化が不要になるためです。 Session ごとに１つのスレッドを貼り付ける限り、アプリケーションはビジネスオブジェクトを synchronize する必要はありません。 Session 内では、アプリケーションはオブジェクトを比較するために、 == を安全に使用できます。

けれども、 Session の外で == を使うアプリケーションは、予期しない結果に遭遇します。これは予期しない場所で起こりえます。例えば、２つの分離インスタンスを同じ Set に put したときなどです。両方とも同じデータベース識別子を持ちます（すなわち、同じ行を表します）。しかし、分離状態のインスタンスの JVM 識別子は当然保証されません。開発者は、永続性クラスの equals() と hashCode() メソッドをオーバーライドし、オブジェクト等価性の概念を実装すべきです。警告が１つあります。等価性の実装にデータベース識別子を使わないでください。ユニークな（普通は不変の）属性の組み合わせであるビジネスキーを使ってください。もし、一時オブジェクトが永続化された場合、データベース識別子が変わります。一時オブジェクトを（通常分離インスタンスと共に） Set に保持する場合、ハッシュコードが変わるということは、 Set の契約を破るということです。ビジネスキーのための属性は、データベースの主キーほど安定すべきではないです。オブジェクトが同じ Set の中にいる間だけ、安定を保証すべきです。この問題のより徹底的な議論は、 Hibernate の Web サイトを参照してください。また、これは Hibernate の問題ではなく、単に Java オブジェクトの識別子や等価性をどのように実装すべきかということです。