Hibernate Books

All times are UTC - 5 hours [ DST ]



Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: Why no batch updates with optimistic concurrency
PostPosted: Wed Apr 14, 2004 12:16 pm 
Newbie

Joined: Mon Mar 22, 2004 5:45 am
Posts: 8
Location: Prague, Czech Republic
Hello,
just wonder why it is not possible.
The executeBatch on JDBC 2.0 PreparedStatement returns counts of updated rows, thus there is potential to check whether it succeeded or not.

Optimistic concurrency is key concurrency approach (often the only usable one) in many applications.

Just don't want to sacriface performance (batch updates) for this.

BR,

Marcel

_________________
Marcel Kruzel
Trema (Czech Republic)
www.trema.com


Top
 Profile  
 
 Post subject:
PostPosted: Fri Apr 16, 2004 5:57 am 
Regular
Regular

Joined: Wed Mar 03, 2004 9:38 am
Posts: 70
As you apparently are aware of, Hibernate uses the updated row count to determine if an update succeeded or not when using optimistic locking with versioning. I.e. if the returned row count is 0, Hibernate throws a StaleObjectStateException.

executeBatch returns an int[] array containing the number of rows updated. However, the problem is that the JDBC spec allows the driver to return -2 instead of the row count, meaning that the statement was executed successfully but there is no information about how many rows where updated (this is really stupid, IMHO). Thus Hibernate cannot necessarily determine if there was an optimistic locking failure or not.

I don't really know how Hibernate handles this problem. Personally I'm using both versioning and batch updates, and it seems to work just fine (PostgreSQL 7.4.2). Perhaps Hibernate just assumes that the user knows what he's doing, i.e. if you try to use both versioning and batch updates with a jdbc driver that returns -2, you'll get some Exception? Or is there some dialect-specific logic that turns off batch updates if you have versioned classes and use a driver known to return -2?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Apr 16, 2004 6:07 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
JDBC drivers do not support the JDBC2 spec very well. At least, they didn't when I wrote that code ;) They just returned -2 instead of the real rowcount.

So Hibernate explicitly disables batching for versioned data.

It might be time to take a closer look at this issue and see how well current versions of JDBC drivers work.

It would actually /simplify/ the code to reenable batch updates with versioned data.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Apr 16, 2004 6:32 am 
Newbie

Joined: Mon Mar 22, 2004 5:45 am
Posts: 8
Location: Prague, Czech Republic
I confirm,
Oracle (classes12.zip) returns -2.

Quite interesting observation is that turning batch updates to off
hibernate.jdbc.batch_size=0
is not so good idea because it influences batch inserts as well.
I figured out (from AbstractEntityPersister and from tests) that when versioned object is being updated (deleted) then the batching is not used no matter what the hibernate.jdbc.batch_size param is specified. Thus specifying it to some not 0 value still makes sense even in cases when optimistic locking is used - the inserts are performed in batches.

BR
Marcel

_________________
Marcel Kruzel
Trema (Czech Republic)
www.trema.com


Top
 Profile  
 
 Post subject:
PostPosted: Fri Apr 16, 2004 7:10 am 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
yup, that is not by accident ;)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Apr 16, 2004 10:15 am 
Regular
Regular

Joined: Wed Mar 03, 2004 9:38 am
Posts: 70
BTW I just tested this and the PostgreSQL 7.4 JDBC driver correctly returns the number of updated rows instead of -2 when using batch updates.

Apparently some older version of this driver did, in fact, return -2, there was some talk about that on the postgresql-jdbc mailing list in 2001.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Jun 22, 2004 4:15 pm 
Newbie

Joined: Thu Apr 08, 2004 10:24 am
Posts: 19
Location: Raleigh, NC
any movement on enabling batched updates for versioned objects?

b


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 09, 2004 10:47 pm 
Regular
Regular

Joined: Fri Dec 12, 2003 2:09 pm
Posts: 84
Location: San Francisco, USA
There's a new Hibernate setting, hibernate.jdbc.batch_versioned_data, to enable batch updates for versioned objects if your JDBC driver implements row counts for batch updates.

Unfortunately, it seems that Oracle's JDBC drivers only return a success/failure code (-2/-3) for standard JDBC batch updates. However, they do return the correct update count if Oracle-specific batching is used.

Two questions for the Hibernate team:
    asfasf
    asdff


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 09, 2004 11:12 pm 
Regular
Regular

Joined: Fri Dec 12, 2003 2:09 pm
Posts: 84
Location: San Francisco, USA
In Hibernate 2.1.5 there's a new setting, hibernate.jdbc.batch_versioned_data, to enable batch updates for versioned objects if your JDBC driver implements row counts for batch updates.

Unfortunately, it seems that Oracle's JDBC drivers only return a success/failure code (-2/-3) for standard JDBC batch updates. However, they do return the correct update count if Oracle-specific batching is used.

Two questions for the Hibernate team:

1. Is it necessary to actually get the update count? It seems that for versioned updates, only a single row is being updated per statement in the batch (since each update has a different version number), and so the update count will always be 1 anyway.

2. What would it require to implement Oracle-specific batch updating? I expect that I'd need to implement a concrete subclass of BatcherImpl, but I'm not sure what else is required or how I'd configure Hibernate to use it?

Thanks!


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 09, 2004 11:24 pm 
Hibernate Team
Hibernate Team

Joined: Tue Aug 26, 2003 12:50 pm
Posts: 5130
Location: Melbourne, Australia
1) You need the rowcount for optimistic locking
2) It should be easy to do an OracleBatcherImpl, and I will add a switch to Hibernate to let you choose a custom batcher, if you submit the request to JIRA

If you can write OracleBatcherImpl completely using reflection (ie. with no compile-time dependency to com.oracle), I will accept it as a new feature of Hibernate.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 10, 2004 12:07 am 
Regular
Regular

Joined: Fri Dec 12, 2003 2:09 pm
Posts: 84
Location: San Francisco, USA
Done and thank you.

http://opensource.atlassian.com/project ... se/HB-1152

No promises on using reflection, although I'll post our Oracle-specific implementation. Just under too many deadlines here at work as is.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Dec 12, 2008 9:13 am 
Newbie

Joined: Thu Apr 19, 2007 10:38 am
Posts: 11
We've developed an OracleBatchingBather a year and a half ago and been using it in our production system for the same time without problems. The solution can be seen here:
http://forums.hibernate.org/viewtopic.php?t=978756

Currently we are rewriting that solution to satisfy what Gavin pointed:
1. no compile-time dependency to com.oracle

and
2. to access native jdbc objects (connections and statements) wrapped by connection pools. In this respect we are looking at how Spring addresses the same issue with their NativeJdbcExtractor.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 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.