jConnect implements batch updates as specified in the JDBC 2.0 API, except as described here:
If the JDBC 2.0 standard for implementing BatchUpdateException.getUpdateCounts is modified or relaxed in the future, jConnect continues to implement the original standard by having BatchUpdateException.getUpdateCounts return an int[ ] length of M < N, indicating that the first M statements in the batch succeeded, that the M+1 statement failed, and M+2..N statements were not executed. Here, “N” equals the total statements in the batch.
To call stored procedures in batch (unchained) mode, you must create the stored procedure in unchained mode. For more information, see “Stored procedure executed in unchained transaction mode”.
If an Adaptive Server encounters an error during batch execution, BatchUpdateException.getUpdateCounts returns only an int[ ] length of zero. The entire transaction is rolled back if an error is encountered, resulting in zero successful rows.
The transaction is not rolled back if the error is a
duplicate key row insert.
In Adaptive Server, a duplicate key row insertion does not result in the termination and rollback of batch statements. The server continues processing the statements in the batch until you issue a cancel or the batch completes or encounters an error other than a duplicate key row insertion. Because jConnect sends a cancel to the server when it detects any exception (including duplicate key row insertion) during batch processing, it is impossible to determine exactly how much of the batch the server executed before receiving the cancel. Therefore, Sybase strongly recommends that in accordance with the JDBC specification, you should execute batches inside of transactions with autoCommit set to “false.” This way, you can roll back your transactions and return the database to a known state before retrying the batch.
Batch updates in databases that do not support batch updates: jConnect carries out batch updates in an executeUpdate loop even if your database does not support batch updates. This allows you to use the same batch code, regardless of the database to which you are pointing.
For details on batch updates see the JDBC API documentation.
