I was looking at the HighLowKeyGenerator in Castor which serves a similar
function to IDBroker. The part of the code that grabs the next base number
and updates the table with the new base number is written like:
rs = stmt.executeQuery();
if ( rs.next() ) {
Object value;
Class valClass;
TypeConvertor back = null;
value = rs.getObject( 1 );
...
if ( back != null ) {
rs.updateObject( 1, back.convert( max, null ) );
} else {
rs.updateBigDecimal( 1, max );
}
rs.updateRow();
last = last.add( ONE );
} else {
stmt = conn.prepareStatement("INSERT INTO " + _seqTable +
" (" + _seqKey + "," + _seqValue +
") VALUES (?, ?)");
stmt.setString( 1, tableName );
stmt.setInt( 2, _grabSize.intValue() );
stmt.executeUpdate();
...
}
This code uses jdbc2.0 api. The documentation states that
" The key generator seeks for the given table name, reads the last reserved
value and increases it by some number N, which is called "grab size". Then
the lock on the auxiliary table is released, so that concurrent transactions
can perform insert to the same table."
I am hoping to get a response from someone who knows the jdbc 2.0 spec
pretty well. Does jdbc2.0 guarantee the table/row is locked between the
stmt.executeQuery() and rs.updateRow() method calls?
And what is the level of compliance among drivers?
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
