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

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?

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.

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

yup, that is not by accident ;)

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.

any movement on enabling batched updates for versioned objects?

b

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

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!

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.

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.

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.