Comments on: Hibernate Tip – Session Closing for Large Imports http://blog.kischuk.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/ Just another WordPress.com weblog Wed, 19 May 2010 15:39:28 +0000 hourly 1 http://wordpress.com/ By: Davide Baroncelli http://blog.kischuk.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-105 Davide Baroncelli Tue, 14 Sep 2004 03:39:21 +0000 http://rkischuk.wordpress.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-105 Nobody showed that Hibernate "doesn't work right": on the contrary, someone pointed out that there is a reason why Hibernate works this way, and it's a (very useful, indeed) feature. Anyway, for anyone that has used Hibernate for more than 10 minutes, and has spent a couple of hours reading the doc, the whole point of this blog entry and the OJB comments is totally screwed, and the "jboss is evil" comments are incredibly lame. Note: I am NOT on the Hibernate/Jboss team, only a happy Hibernate user, which respects a lot Gavin's work: try to give a look to the inner Hibernate architecture, before saying it's "shitty". Nobody showed that Hibernate “doesn’t work right”: on the contrary, someone pointed out that there is a reason why Hibernate works this way, and it’s a (very useful, indeed) feature. Anyway, for anyone that has used Hibernate for more than 10 minutes, and has spent a couple of hours reading the doc, the whole point of this blog entry and the OJB comments is totally screwed, and the “jboss is evil” comments are incredibly lame. Note: I am NOT on the Hibernate/Jboss team, only a happy Hibernate user, which respects a lot Gavin’s work: try to give a look to the inner Hibernate architecture, before saying it’s “shitty”.

]]> By: Anonymous http://blog.kischuk.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-104 Anonymous Mon, 13 Sep 2004 13:47:59 +0000 http://rkischuk.wordpress.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-104 Of course, any time Hibernate doesn't work right, it's the users fault. The authors love to point that out every time they can. Don't you love it when a vendor tells it's users that they are wrong so much? Of course, any time Hibernate doesn’t work right, it’s the users fault. The authors love to point that out every time they can.

Don’t you love it when a vendor tells it’s users that they are wrong so much?

]]> By: Jason Carreira http://blog.kischuk.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-103 Jason Carreira Mon, 13 Sep 2004 11:56:19 +0000 http://rkischuk.wordpress.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-103 In addition to the Hibernate tips above, I'll add that in my experience building large scale batch processing frameworks, it's usually a good idea to commit every x records so as not to keep a transaction open while you process 100,000+ records. It does make batch recovery a bit more tricky though, since it's not all one transaction, but you could create a temp table or something and do a "select into"... In addition to the Hibernate tips above, I’ll add that in my experience building large scale batch processing frameworks, it’s usually a good idea to commit every x records so as not to keep a transaction open while you process 100,000+ records. It does make batch recovery a bit more tricky though, since it’s not all one transaction, but you could create a temp table or something and do a “select into”…

]]> By: Gavin http://blog.kischuk.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-102 Gavin Tue, 24 Aug 2004 21:11:56 +0000 http://rkischuk.wordpress.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-102 The comments about OJB are incredibly ill-informed. The reason for the "cache everything unless explicitly told not to" policy is to enable automatic dirty checking, a feature that OJB does not have in its PersistenceBroker API. You can *at any time* flush() then clear() the session cache. It's funny. You will need to explicitly call flush()/clear() much, much, much less often in your application than you would need to explicitly call update() in OJB PersistenceBroker. So you guys are so wrong it hurts. The comments about OJB are incredibly ill-informed.

The reason for the “cache everything unless explicitly told not to” policy is to enable automatic dirty checking, a feature that OJB does not have in its PersistenceBroker API.

You can *at any time* flush() then clear() the session cache. It’s funny. You will need to explicitly call flush()/clear() much, much, much less often in your application than you would need to explicitly call update() in OJB PersistenceBroker.

So you guys are so wrong it hurts.

]]> By: Juha Komulainen http://blog.kischuk.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-101 Juha Komulainen Sat, 21 Aug 2004 16:18:03 +0000 http://rkischuk.wordpress.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-101 <p> Yes, if you have a large batch of data, it is probably worthwhile to call Session.flush() every once in a while. This will execute the SQL to insert the data into the database, but won't remove the object from session cache and your session will still grow. So you'll also want to remove the object from session cache by calling Session.evict(Object) after flushing. </p> <p> Of course this manual flushing and evicting is only necessary when you have huge amount of data (like your 40,000 records) to insert in batch. </p> Yes, if you have a large batch of data, it is
probably worthwhile to call Session.flush()
every once in a while. This will execute the
SQL to insert the data into the database, but
won’t remove the object from session cache and
your session will still grow. So you’ll
also want to remove the object from session
cache by calling Session.evict(Object) after
flushing.

Of course this manual flushing and evicting is
only necessary when you have huge amount of data
(like your 40,000 records) to insert in batch.

]]> By: Adrian http://blog.kischuk.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-100 Adrian Thu, 19 Aug 2004 01:28:47 +0000 http://rkischuk.wordpress.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-100 have you tried to flush() your Hibernate session ? I's significantly cheaper than reopening a session and you can do it in smartly sized batches. My experience shown that Castor 'JDO' and OJB are slower that Hibernate if your code is properly tuned. have you tried to flush() your Hibernate session ? I’s significantly cheaper than reopening a session and you can do it in smartly sized batches.

My experience shown that Castor ‘JDO’ and OJB are slower that Hibernate if your code is properly tuned.

]]> By: Rob Kischuk http://blog.kischuk.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-99 Rob Kischuk Wed, 18 Aug 2004 23:21:54 +0000 http://rkischuk.wordpress.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-99 Already had to dump OJB. <p> We gave OJB the first shot. The problem we ran into had to do with OJB/JBoss and some silly eager-release attribute. Memory isn't perfect on this one, but essentially if it was false, it led to some resource consumption error. If true, then it would only load the first element of a collection, the 2nd element would load on the 2nd call to that collection, and so on. <p> In short, no matter which way we set the stupid configuration parameter, there was going to be an unacceptable consequence. Thought inconvenient, Hibernate is working for us. Already had to dump OJB.

We gave OJB the first shot. The problem we ran into had to do with OJB/JBoss and some silly eager-release attribute. Memory isn’t perfect on this one, but essentially if it was false, it led to some resource consumption error. If true, then it would only load the first element of a collection, the 2nd element would load on the 2nd call to that collection, and so on.

In short, no matter which way we set the stupid configuration parameter, there was going to be an unacceptable consequence. Thought inconvenient, Hibernate is working for us.

]]> By: Anonymous http://blog.kischuk.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-98 Anonymous Wed, 18 Aug 2004 17:39:14 +0000 http://rkischuk.wordpress.com/2004/08/18/hibernate-tip-session-closing-for-large-imports/#comment-98 Yes, we found this problem. The solution to the problem - switch to OJB. Our problems with the pointless "cache everything until you commit" feature went away. <br> The Hibernate folks keep saying - why hit the database when you don't have to. I think the opposite, if you are writing data to the database, why cache it up. You are going to have to write it at some point, how does caching a write help? A database is extremely good at handling transactions, why replicate it in Hibernate and have users have problems like this. <br> Of course, the JBoss people are very good at implementing very shitty things and not listening to their users about fixing them. Like the JBoss classloader and the multi-cast clustering. <br> Switch to OJB and it will run even faster. Yes, we found this problem. The solution to the problem – switch to OJB. Our problems with the pointless “cache everything until you commit” feature went away.

The Hibernate folks keep saying – why hit the database when you don’t have to. I think the opposite, if you are writing data to the database, why cache it up. You are going to have to write it at some point, how does caching a write help? A database is extremely good at handling transactions, why replicate it in Hibernate and have users have problems like this.

Of course, the JBoss people are very good at implementing very shitty things and not listening to their users about fixing them. Like the JBoss classloader and the multi-cast clustering.

Switch to OJB and it will run even faster.

]]>