-->
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.  [ 4 posts ] 
Author Message
 Post subject: Question about flushing and transactions
PostPosted: Mon Mar 20, 2006 4:40 pm 
Beginner
Beginner

Joined: Wed Nov 30, 2005 4:58 pm
Posts: 22
Location: Austin, TX
Suppose code like this:

Code:
Session session = sessionFactory.openSession ();
try {
  Transaction tx = session.beginTransaction ();
  Person p = session.load (Person.class, id);
  session.delete (p);
  session.evict (p);
  ...
  p = new Person (id); // same id as above
  session.save (p);
  tx.commit ();
} catch (Exception e) {
  tx.rollback ();
}
finally {
  session.close ();
}


If I omit the evict() call, I get a NonUniqueObjectException. If I include the evict() call I get org.hibernate.AssertionFailure: possible nonthreadsafe access to session. Only one thread has access to the session and mapped objects managed by the session. I'm specifying FlushMode.COMMIT to flush when a transaction commits.

Questions:

1) Some posters have used flush() instead of evict() as a solution, and indeed, it solves it for me too. How does flushing effect the transaction? If data is flushed, can it still be rolled back later in the same transaction?

2) Is Hibernate being overly agressive about the assertion? Is it safe to ignore it in this case?

Hibernate version: 3.0.2

Name and version of the database you are using: mysql


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 20, 2006 5:32 pm 
Beginner
Beginner

Joined: Tue Aug 23, 2005 3:52 pm
Posts: 26
Hibernate attempts to make minimum amount of calls to db, this means it will try to send data to db at the last possible moment. If I am not mistaking this is called "write behind or write back". What flush does is, it forces Hibernate to send a call to the db.

I don't know if that helps but this is my 2 cents.
Leonid


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 20, 2006 5:47 pm 
Beginner
Beginner

Joined: Wed Nov 30, 2005 4:58 pm
Posts: 22
Location: Austin, TX
Yeah, that makes sense that it would want to minnimize interaction with the DB. However, I'm still unclear on what you mean by "[flush()] forces Hibernate to send a call to the db." Is it committed? If not, can it be rolled back? Can another session/transaction that was started after my flush() see the data that was flushed before I explicitly call commit()? I guess I'm unclear on the differences between flush() and commit().


Top
 Profile  
 
 Post subject:
PostPosted: Mon Mar 20, 2006 7:00 pm 
Beginner
Beginner

Joined: Tue Aug 23, 2005 3:52 pm
Posts: 26
Flush sends db call to the db and opens the transaction. Commit commits the transaction. That means that you transaction will not bee seen on the db untill the first flush. Regarding the visibitlity of your transaction it depends on the lock mode that you use and what is the corresponding lock that Hibernate sets on the DB.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 4 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.