Hibernate Bulk Insert is not Working for me.....

Hi,
I am using
hibernate version 3.1.2
spring version 2.0

My model names are Components and Process.


For Bulk insert I was trying this....

for (int i = 0; i < 1000; i++) {
hibernateTemplate.save(components.get(i));
}

for (int i = 0; i < 1000; i++) {
hibernateTemplate.save(processes.get(i));
}

Instead of Single insert like this.....


for (int i = 0; i < 1000; i++) {
hibernateTemplate.save(components.get(i));
hibernateTemplate.save(processes.get(i));
}

I read up on the following links to understand bulk insert
[url]http://forum.hibernate.org/viewtopic.php?t=929812[/url]
[url]http://opensource.atlassian.com/projects/hibernate/browse/HHH-1[/url]
[url]http://www.hibernate.org/hib_docs/v3/reference/en/html/batch.html[/url]

My problem is that both way the time taken is the same...........

I tried putting trace on SQL 2005 database and I dint see any difference in queries also.......
Can u please help me and tell me how do I make this Hibernate Bulk Insert Work????

In my test-beans.xml I have these following entries......

<bean id="sessionFactory" class="org.springframework.orm.hibernate3.annotation.AnnotationSessionFactoryBean">
............
............

<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.HSQLDialect</prop>
<prop key="hibernate.hbm2ddl.auto">create</prop>
<prop key="hibernate.show_sql">false</prop>
<prop key="hibernate.cache.use_second_level_cache">false</prop>
<prop key="hibernate.cache.use_query_cache">true</prop>
<prop key="hibernate.cache.use_structured_entries">true</prop>
<prop key="hibernate.generate_statistics">true</prop>
<prop key="hibernate.jdbc.batch_size">35</prop>
</props>
</property>

....................
</bean>

Now two important things to note here is
1. hibernate.cache.use_second_level_cache set to false
2. hibernate.jdbc.batch_size set to 35

Now I believe this is all the setting needed.


Thanks and waitng in anticipation.....

Just do not use that HibernateTemplate from Spring :)

I did not check the Spring 2 implementation but in Spring 1 it would do all its methods in separate transactions.

It is better to inject Hibernate session in your bean and wrap it in the transaction interceptor. The method is explained in the Spring documentation right after the evil HibernateTemlate.
or here http://www.onjava.com/pub/a/onjava/2005 ... tml?page=1

The Session thing is fine. Also we can use hibernateTemplate.saveOrUpdateAll(Collection) to achieve Hibernate Bulk Insert.

I understand that HibernateTemplate is a debated topic. I'm looking to get away from using it. Could you give some detail on how you would set up the DAO classes by injecting the hibernate session?

I'm not sure what you're talking about when you say that HibernateTemplate would do all it's methods in separate transactions. I'm looking at the source code for 1.2.8 and it seems to use the same session and checks to see if there is a current transaction running.

It looks like my knowledge is out of date. Thanks for pointing at my mistake.

I am also facing the same problem during bulk insert.
Please update this forum if anyone has solution to this issue.

Thanks,
Sivaprakash S

I found this post, me and my team are facing the same problem, we cannot understand how we are supposed to use HibernateTemplate in Spring to achieve batch inserts as it is indicated in the Hibernate Tutorial.

Thanks for any help !


Karim

Karim, take a look at this tutorial:

http://www.onjava.com/pub/a/onjava/2005/05/18/swingxactions.html?page=1

for starters, the Hibernate Template is crap. stop using it immediatly. even the Spring people themselves advise against it. look here: http://blog.springsource.com/main/2007/06/26/so-should-you-still-use-springs-hibernatetemplate-andor-jpatemplate.

if you still dont understand how to avoid the session-per-operation anti-pattern do the following. note, this is a solution leveraging the traditional session-per-request design pattern.

ur DAO implementation classes should all be injected with a sessionfactory.

when a DAO operation is invoked, use Hibernate 3's support for contextual sessions and call sf.getCurrentSession() and then use the session to perform your persistence operations.

now, you may be wondering how does hibernate know when to open/close a session/transaction. transaction demarcation will happen at a higher level in your application, usually somewhere in your service layer. the ideal solution is to create an AOP aspect that performs your transaction demarcation. the aspect will of course be bound to the hibernate transaction API (or JTA if thats what your using), but this is ok. your tx aspect should wrap your service methods using the traditional Before/AfterReturning/AfterThrowing advice to begin/commit/rollback (respectively) the transaction.

when it comes to bulk updates, avoid the Session api entirely, use the StatelessSession API. search for other threads with my username for more info on how to properly perform bulk operations.

Great post, bennini. Hibernate advice with an attitude. I like it. :)



I simply can't stress this point enough. I can't tell you how many people are architecting solutions where transaction demarcation happens insider or behind the DOA, rather than in front of it. Or where people are sending every call through a stateless session bean EJB, and each method on the stateless session bean is set with a transactional attribute of REQUIRES_NEW.

The back end is responsible for managing the persistence code, but it should be responsible for the transaction demarcation. Let that be done at a higher level, indeed.

And many people are still confused about the getSession and openSession thing. I will admit, the JavaDocs aren't overly in depth with regards to the distinction. People should know to go with getSession unless they have a compelling reason to do otherwise.

haha thanks. i used to use the HibernateTemplate back before i understood anything. now that i look back, i was using a framework to simplify another framework. thats exactly what anti-java people refer to when they mention framework bloat and complexity.


i think u meant to write "should NOT BE responsible", right?

the problem with the whole idea of where to properly demarcate transactions (and in hibernate's case, Sessions) is the following:

1. it is always said that a DAO should hide all persistence logic. if people see Hibernate code like session.beginTransaction(), the first reaction is, ok its hibernate related so it has to be hidden behind a DAO interface. this is wrong and leads to the session-per-operation anti-pattern

2. back before AOP and the whole contextual session management from Hibernate 3, it was very unclear as to how one should demarcate a transaction without binding your service level to a transaction API (and in this case Hibernate). so immediately people dont (or at least i didnt for a long time) fully understand how one encapsulates persistence related code from higher layers in an application

3. in web containers there was always the Open Session in View pattern but this wasnt/isnt applicable for stand alone applications that arent modeled around the "session-per-request" pattern. in my eyes, its still not clear for people that are new to java and this whole domain as to how one should demarcate a transaction in a stand alone application without the help of AOP or some direct invocation of the "start/stop/rollback" methods from within service layer objects.

i wish i could draw a picture on here. i think it would clarify a lot of stuff for people new to this stuff

I was thinking more about application layering. What I meant is more important than what I said. :)

But yes, precisely.

I think people are getting it, slowly but surely.