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