JDBC: Fix executeBatch Array Sizing Issue to Prevent Memory and Overflow Errors

Details

Detail name Value
Changelog Number 26876
Type Bug
Status Resolved
Affected Versions Exasol 7.1.0
Fix Versions JDBC 26.2.10
Resolution Date 2026-10-13

Description

In the AbstractEXAPreparedStatement.executeBatch() JDBC driver method, the result array (int[] ret) size was incorrectly calculated based on the total number of affected rows (retUp) from the batch operation instead of the number of batched statements (batch_pos). This led to two major issues in scenarios where batch operations affected a very large number of rows:

  1. Memory Issues: A large number of rows affected by the batch resulted in the creation of an excessively large array, consuming substantial memory and potentially causing OutOfMemoryError.
  2. Overflow Issues: If the total number of affected rows exceeded the int data type limit (2,147,483,647), it caused an integer overflow, resulting in a NegativeArraySizeException when attempting to allocate an array with a negative size.

The bug has been fixed by ensuring that the size of the result array is calculated based on the number of batched statements (batch_pos). This change adheres to the JDBC contract, prevents memory and overflow issues, and ensures that the executeBatch() method functions correctly in high-volume data processing scenarios.

Workaround

Users facing this issue while working with earlier driver versions can mitigate the problem by reducing the size of their batches. Specifically, break large batches into smaller batches such that each batch does not affect an excessive number of rows.

For example, instead of batching 100 DELETEs that each affect 1,000,000 rows, split it into batches of 10 DELETEs per executeBatch call.

Fix

The executeBatch method has been updated in the AbstractEXAPreparedStatement class:

  • The size of the result array (int[] ret) is now correctly determined by the number of batched statements (batch_pos) rather than the total number of affected rows (retUp).
  • The implementation now adheres to the JDBC specification and prevents excessive memory use or array size overflow, improving reliability for batch operations with high affected row counts.