-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 
Author Message
 Post subject: Inserts in batches, page 538, Java Persistance with Hibernat
PostPosted: Thu Jan 03, 2008 8:47 am 
Newbie

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.


Top
 Profile  
 
 Post subject: modulo
PostPosted: Thu Jan 03, 2008 3:56 pm 
Expert
Expert

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.

_________________
Gonzalo Díaz


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.