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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev