[hibernate-dev] Multiple-object batched inserts

[Steve Ebersole]

Wanted to point out that a Map keyed by SQL is not sufficient, because that 
approach would not properly account for self-referential associations (the 
same SQL).  

The patch provided for HHH-1 is well thought out in terms of accounting for 
all association scenarios.  It does not, of course, handle multi-table 
structures which require a much different type of solution given how 
Hibernate groups the DML for these behind the persisters (I know the general 
approach I will use to solve this one now, btw).

On Thursday 23 August 2007 01:32:02 am Max Rydahl Andersen wrote:
> http://opensource.atlassian.com/projects/hibernate/browse/HHH-1
>
> /max
>
> > I thought his question was a little too technical for the general list,
> > so I thought I¹d ask it here.  Is there a technical reason why Hibernate
> > does not or cannot support the batching of multiple (different) object
> > insertions within the same session?
> >
> > I have code that is semantically equivalent to:
> >
> > Session session = sessionFactory.getCurrentSession();
> > for (int i = 0; i < 1000; i++) {
> >    Foo foo = new Foo();
> >    session.save(foo);
> >
> >    Bar bar = new Bar();
> >    session.save(bar);
> > }
> > session.flush();
> >
> > If Foo or Bar is not in the equation, batching occurs as desired. 
> > However, if both Foo and Bar are inserted during the session in
> > alternating fashion the result is that in the ActionQueue the 'insertion
> > list' is interleaved with Foo's and Bar's.  This is natural enough it
> > seems.  However, when ActionQueue.executeActions() is called the
> > following occurs...
> >
> > 1) executeAction() iterates through the insertion list calling execute()
> > on each Executable in the list
> > 2) the Executable.execute() method calls insert() on the associated
> > persister, in the case a SingleTableEntityPersister.  It seems to realize
> > that it CAN batch these inserts and so ...
> > 3) insert() calls the BatchingBatcher.prepareBatchStatement(sql) which is
> > actually a method on AbstractBatcher.  This is where things go "awry"...
> >
> > The prepareBatchStatement(sql) does this thing where it compares the SQL
> > statement that was provided with the _last SQL that it executed_ and if
> > they match it re-uses the _last PreparedStatement_ which it also hung
> > onto, otherwise it closes the existing PreparedStatement and creates a
> > new one -- effectively ending the current "batch".
> >
> > In this case, because the objects are interleaved in the insertion list
> > the result is that the prepareBatchStatement() is called with:
> >
> > insert into foo (a, b, c) values (?, ?, ?)
> > insert into bar (x, y, z) values (?, ?, ?)
> > insert into foo (a, b, c) values (?, ?, ?)
> > insert into bar (x, y, z) values (?, ?, ?)
> > insert into foo (a, b, c) values (?, ?, ?)
> > insert into bar (x, y, z) values (?, ?, ?)
> > ...
> >
> > The result being that each subsequent statement terminates the statement
> > prepared before it, preventing batching from occuring.  Well, it logs a
> > debug message saying "Executing batch size: 1" for each statement.
> >
> > So my question is this ... is there any reason not to use a Map<sql,
> > PreparedStatement> construct in the BatchingBatcher such that the
> > appropriate PreparedStatement can be located and re-used based on the
> > incoming SQL rather than only retaining the _last_ SQL statement which is
> > guaranteed to "flap" in the case of alternating (or multiple) objects?
> >
> > If there is no technical reason why this shouldn't be done or wouldn't
> > work, I will be happy to make the change and submit a patch.  [Can you
> > tell how bad I need batching in this scenario?]
> >
> > Thanks,
> > Brett Wooldridge
> > The ZipTie Project
> > www.ziptie.org
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev