In chapter 10.4.2 of the doc, one can read the following:

Each interaction with the persistent store occurs in a new Session. However, the same persistent instances are reused for each interaction with the database. The application manipulates the state of detached instances originally loaded in another Session and then "reassociates" them using Session.update() or Session.saveOrUpdate().

This looks fine until we want to query using one of those objects loaded in a previous session and not yet reassociated with the current one (say because the business transaction is not yet completed).

Example:
The modification of an employee record takes several http requests to complete (long business transaction spanning multiple user requests). We load the employee record at the first request and apply changes to this copy until done. Those changes are not persisted to the database since the employee record is not reassociated with the current session until the end of the business transaction. At the end, changes are persisted using a call to session.update().

Now at some point in the business transaction, we need to search for activities performed by the employee. This information isn't available directly from the employee object so a complex Hibernate HQL query is needed. This query takes the employee as argument.

Unfortunately, this doesn't work seemlessly because the employee is not in the current session.

We could load it by id - but this may cause a duplicate entity in the session if we issue a call to session.update() in the same transaction (see above).


Question is: how can we solve this issue properly ?