Andrus Adamchik wrote:
>"OracleStatement.noMoreUpdateCounts" field has default access (so it is
>package-visiable), so are you creating a dummy class in oracle.jdbc.driver
>package to get access to this variable?
>
not exaclty, I used a public field (via reflection) and an exception
within the "PreparedStatementWrapper" of the statement cache:
public int[] executeBatch () throws SQLException {
// oracle driver patch
try {
if ( oracleClosedFlag != null ) {
oracleClosedFlag.setBoolean( pstmt, true );
try {
pstmt.executeUpdate();
throw new Error("uuuups!");
} catch ( SQLException sqle ) {}
oracleClosedFlag.setBoolean( pstmt, false );
}
}
catch ( Exception e )
{
throw new SQLException( "exception in oracle patch: " + e );
}
return pstmt.executeBatch ();
}
>In other words, we need to support those other (sane) cases of simpler and
>more efficient checking of optimistic lock failures from update counts
>(batched or not).
>
I can create a mininal list of objects with possible
conflicts based on the available info.
The "-2" is jdbc-spec conform, I can
evaluate this and use the getUpdateCount
as a fallback only.
Could be worse looking at what the Hibernate
people did. I browsed through their web-pages
and saw that they claim to support
- a prepared-statement cache
- Oracle
- batch updates
- optimistic lock based on version and/or timestamp
So they must have solved all this?
(Though I'm afraid this cut's down
to supporting "x OR y OR z" ...)
Greetings from old Europe,
Arndt
This archive was generated by hypermail 2.0.0 : Wed May 28 2003 - 09:36:33 EDT