Inserts in batches, page 538, Java Persistance with Hibernat

jambalaya · **Joined:** Sat Oct 28, 2006 3:05 pm **Posts:** 10

The page gives the following code:

Code:

for ( int i=0; i<100000; i++ ) {
    Item item = new Item(...);
    session.save(item);
    if ( i % 100 == 0 ) {
        session.flush();
        session.clear();
    }
}

and says beneath:

Quote:

(...)remember to set the hibernate.jdbc.batch_size configuration property to an equivalent value and disable the second-level cache for the persistent class(...)

- equivalent value here means 100.

In the first iteration, i is 0, and 0 % 100 is 0, so the session gets flushed and cleared, but underlying jdbc does not (1 is not 100). Doesn't the session then get out of sync with the underlying jdbc batch size? (won't hibernate be, so as to call it, 1 row behind jdbc?) Or maybe this is not a problem at all?

This same piece of code is also in the reference guide, 13.1 Batch inserts.

However, there are another listings when it comes to batch updates:

Code:

int count=0;
while ( itemCursor.next() ) {
    Item item = (Item) itemCursor.get(0);
    modifyItem(item);
    if ( ++count % 100 == 0 ) {
        session.flush();
        session.clear();
    }
}

This in turn stays in sync with jdbc (of course, if my previous assumption was correct), because the first iteration increments i before it computes the modulo. The same code can be found in the reference.

Can you guys please explain this issue?
Thanks.

gonzao_diaz · **Joined:** Mon Nov 26, 2007 2:29 pm **Posts:** 443

Your question seems more about the nature of the modulo operation, rather than about Hibernate.

I believe that the idea behind the first code snippet is simply to illustrate a batch processing technique. You point out correctly that the modulo of 0 is 0, therefore the flush is executed at items 0 and 100.

However, in regard to JDBC being "out of synch", I don't see why.

A "save" operation executes the insert immediately (which kind of defeats the purpose of batch processing, in my opinion).

The second code snippet makes more sense, provided that the "modifyItem" method calls "persists" and the whole thing is surrounded by a transaction.