We use hibernate since years in a client-server application.
The application handles a huge amount of loaded hibernate objects and work with long running sessions.
A user of this application manipulates this objects in many ways.
We use flush and rollback to control this manipulations. So we use rollback to undo the results of manipulation.
To synchronize with database we refresh the manipulated objects only.
Because of the huge amount of objects these selective refresh is absolutely necessary to get a reasonable performance.

Hibernate 5.2.0 changed the behavior of rollback. Now StatefulPersistenceContext.clear() is called which calls unsetSession() on proxies and collections.

This happens by a change in



Before Hibernate 5.2:



Since Hibernate 5.2



As a result of this: objects are without session und all objects have to be refreshed. This is a performance issue.

How to deal with his situation?
Is there a way to rollback the database session without unsetSession() of objects and collections?
Have we overlooked a way to configure this?

Does hibernate definitely considers rollback as the end of Session?

Any suggestions?

There are several statements which are worrisome in your data access patterns:

1. Assuming you are using an MVCC engine (e.g. Oracle, PostgreSQL, MySQL InnoDB), there's a huge performance penalty for running long-running transactions, and rolling back a huge version history
2. Refresh does not work like an undo since there might be entity state transitions that have cascaded to child entities. Check out the refresh gotchas User Guide section.

Now, related to that change, a rollback is usually triggered by a RuntimeException. In this case, rolling back and clearing the Session is the right thing to do because you can no longer guarantee that the state of the currently attached entities.

Why don't you try to use a different mechanism for handling all changes in-memory without applying any intermediate change to the database? This will perform way better and it's a typical pattern in multi-request logical transactions where only the last request uses a read-write database transaction.

Thanks for your answering so fast.
To 1) We have huge number of objects. But during a session only a small amount of them are manipulated. So the database rollback itself is no performance problem.
To 2) You are right. Refresh is just one thing, we also care about new and deleted objects. It works.

And you are right, that in case of exception a rollback and a session close is the only correct way.

Let me explain why flushing during a session:
We also use HQL-selects during the session. Hibernate merges the result of the select with the information in the hibernate session. In our case this merge is not fast enough . It is much faster to flush first and then select.

I understand your approach of just one database access at end of session (commit or rollback). This approach is also explained in hibenate user guide.
But our issue is performance.

Hibernate always flushes before any HQL. Check out this article for more info.



Hibernate doesn't do any such merge. Either it gives you the entity if it's stored in the currently running Session, or the entity that was build from the incoming ResultSet. There's no automatic merging unless you call merge, in which case you'll end up with a different entity instance on Heap.

In version 4.2 we had a performance increase by working this way:



Without that method, we detected that hibernate was comparing (this compare I called merge) the objects of resultset with the objects in hibernate cash (calls equals for each object in hibernate cash). We have approximately 50.000 objects in cash.