We're attempting to upgrade from 4.2.8 to 4.3.1, and have encountered an issue that I believe stems from the loader rewrite in 4.3.0.

The issue is an obscure one, but can have serious consequences. It involves when you have a detached object that is part of a composite primary key of a second object - via an @Embeddable reference.

If you attempt to load the second object (nb. and the load succeeds), using the reference to the detached object, then that detached object becomes accidentally bound to the current session - without any merge / update stage from the underlying database. Subsequent get() calls will return that same object from the first-level cache... and that object may be invalid and does not necessarily represent the current state of the underlying database.

This did not happen using Hibernate 4.2.8.

A test case is attached. Note that this depends some of our own transaction management classes, you will have to re-implement the transaction handling / sessionFactory handling in your own environment.

The failure is demonstrated by the Assert statement at the end of the third transaction - where a new entity should have been loaded from the database, yet the previously detached entity has been returned in it's place, and the Assert statement fails. In Hibernate 4.2.8, the test passes, as the new entity is loaded from the database.