Batched statements fail when a trigger produces a result set

There appears to be a special case involving batched statements and triggers that the driver does not handle correctly.

The application executes a statement using batching. The statement itself is valid, but the target table has a TRIGGER which performs an operation that produces a result set. When the statement is executed normally (without batching), the operation works as expected. However, when the same operation is executed as a batch, the driver does not correctly handle the result generated as part of the trigger execution, causing the batch operation to fail.

This appears to be a driver-level issue rather than an issue with the SQL statement or the trigger itself.

Why this is a special case

The important aspect of this case is that the result-producing operation occurs inside the trigger. The application code executing the original statement does not directly request or expect that result set.

Consequently, application code cannot simply consume the result in the normal way. The driver needs to correctly handle the result(s) generated while processing the batched statement and its trigger execution.

This also makes the issue difficult to work around at the application level.

Impact

There does not appear to be a practical workaround that preserves the existing behavior and architecture.

The possible workarounds are:

Modify the trigger so that it no longer produces the result that causes the problem.
This may not be possible in some environments because the trigger is managed separately from the application, is shared by multiple applications, or cannot be changed for compatibility/business reasons.

Stop using batching for this operation.
This requires rewriting the application code to execute the statements individually. Depending on the application, this may have significant performance implications and could also introduce behavioral changes associated with replacing an existing batch operation.

Neither of these is a satisfactory workaround for an application that needs to retain both the existing trigger and batched execution.

Expected behavior

The driver should correctly execute the batch and handle any results generated during trigger execution according to the JDBC/API contract, without requiring the application to modify the trigger or abandon batching.

In particular, a result generated as a side effect of trigger execution should not cause an otherwise valid batched statement to fail merely because the statement was executed through the batch API.

Actual behavior

When the statement is executed as a batch and the trigger produces the relevant result, the batch operation fails with an ArrayIndexOutOfBoundsException within the driver's code.

The same operation succeeds when batching is not used.

Reproduction

A minimal reproduction should consist of:

CREATE TABLE test_table (
id INT PRIMARY KEY
);

– Trigger which produces the result involved in the problem.
– [Insert the exact trigger definition here.]

INSERT INTO test_table (id) VALUES (1);

Then execute the statement both ways:

// Non-batched execution
PreparedStatement ps = connection.prepareStatement(
"INSERT INTO test_table (id) VALUES "
);
ps.setInt(1, 1);
ps.executeUpdate();

and:

// Batched execution
PreparedStatement ps = connection.prepareStatement(
"INSERT INTO test_table (id) VALUES "
);
ps.setInt(1, 1);
ps.addBatch();
ps.executeBatch();

The non-batched version succeeds, while the batched version encounters the driver problem when the trigger produces the result.

I'll be attaching a complete reproducer which demonstrates some situations where the driver has no issues, and one case where the driver fails with an AIOOBE.