-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 
Author Message
 Post subject: Hibernate 5.2.0 changed the behavior of rollback.
PostPosted: Fri Dec 09, 2016 7:49 am 
Newbie

Joined: Thu Dec 08, 2016 11:21 am
Posts: 6
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

Code:
SessionImpl.afterTransactionCompletion(boolean successful, boolean delayed)


Before Hibernate 5.2:

Code:
SessionImpl.afterTransactionCompletion(boolean successful, boolean delayed) {

if ( autoClear ) {   internalClear(); }
… }


Since Hibernate 5.2

Code:
SessionImpl.afterTransactionCompletion(boolean successful, boolean delayed) {

if ( autoClear ||!successful ) { internalClear();  }
… }


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?


Top
 Profile  
 
 Post subject: Re: Hibernate 5.2.0 changed the behavior of rollback.
PostPosted: Fri Dec 09, 2016 8:13 am 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1630
Location: Romania
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.


Top
 Profile  
 
 Post subject: Re: Hibernate 5.2.0 changed the behavior of rollback.
PostPosted: Fri Dec 09, 2016 10:09 am 
Newbie

Joined: Thu Dec 08, 2016 11:21 am
Posts: 6
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.


Top
 Profile  
 
 Post subject: Re: Hibernate 5.2.0 changed the behavior of rollback.
PostPosted: Fri Dec 09, 2016 10:16 am 
Hibernate Team
Hibernate Team

Joined: Thu Sep 11, 2014 2:50 am
Posts: 1630
Location: Romania
Quote:
It is much faster to flush first and then select.


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

Quote:
Hibernate merges the result of the select with the information in the hibernate session.


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.


Top
 Profile  
 
 Post subject: Re: Hibernate 5.2.0 changed the behavior of rollback.
PostPosted: Fri Dec 09, 2016 10:53 am 
Newbie

Joined: Thu Dec 08, 2016 11:21 am
Posts: 6
In version 4.2 we had a performance increase by working this way:

Code:
FlushMode flushMode = getPersistenceContext().getSession().getFlushMode();
getPersistenceContext().getSession().setFlushMode(FlushMode.MANUAL);
getPersistenceContext().getSession().flush();
Query query = getPersistenceContext().getSession().getNamedQuery(queryId);
query.setReadOnly(readOnly);
setParameter(query, queryName.getParamNames(), paramValues);
Iterable iter = query.list();
getPersistenceContext().getSession().setFlushMode(flushMode);


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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.