On Saturday, May 24, 2003, at 04:16 PM, Arndt Brenschede wrote:
>
> This is the same "-2" you see in the log if you run the context-commit
> on DEBUG level.
>
> You should note the fully useless assigment in the line before
> the return - this is an indication on what level of java developers
> wrote this spaghetti.
Funny that Oracle actually thinks that this is a desired behavior - the
docs for "OraclePreparedStatement.executeUpdate" mention "-2" as the
returned value of this method.
> Anyhow, I did a real bad hack
> in my prepared statement cache
> to make getUpdateCount work,
> but I think for the individual
> update counts there's no chance
> for oracle.
You are right. It looks much worse than I thought. Given that
"getUpdateCount" result is correct, or we can make it correct (I don't
completely understand the problems you are having with it), we will
need to build a hell of a query detecting failed rows to analyze
optimistic lock failures .... In the worst case scenario, if a batch
consists of thousands of rows, and a primary key is compound (so that
IN() can't be used), WHERE clause is gonna be *very* long.
BTW, I am adding the value returned by getUpdateCount to the logging
output.
Andrus
This archive was generated by hypermail 2.0.0 : Sun May 25 2003 - 14:53:28 EDT