> Does it allocate memory anywhere else? The OutOfMemory error happens
> several seconds after entering executeBatch(). So the parameter List
> has already been created, and Jaybird is only iterating through it.

A bit, but not so much. Below is the code of that method:

public int[] executeBatch() throws SQLException {

Object syncObject = getSynchronizationObject();

LinkedList results = new LinkedList();
Iterator iter = batchList.iterator();

boolean commit = false;
synchronized(syncObject) {
c.ensureInTransaction();
XSQLVAR[] backupVars = null;
try {
while(iter.hasNext()) {
XSQLVAR[] data = (XSQLVAR[])iter.next();

XSQLVAR[] vars = fixedStmt.getInSqlda().sqlvar;
for (int i = 0; i < vars.length; i++) {
vars[i].copyFrom(data[i]);
isParamSet[i] = true;
}

try {
if (internalExecute(isExecuteProcedureStatement))
throw new BatchUpdateException(
toArray(results));

int updateCount = getUpdateCount();

results.add(new Integer(updateCount));

} catch(SQLException ex) {
throw new BatchUpdateException(
ex.getMessage(),
ex.getSQLState(),
ex.getErrorCode(),
toArray(results));
}
}

commit = true;

return toArray(results);

} finally {
clearBatch();
c.checkEndTransaction(commit);
}
}
}

So, there are two possibilities:

a) vars[i].copyFrom(data[i]) - copies content of the stored parameter to the
parameter associated with the statement. It makes a deep copy including the
byte[] with data.

b) results.add(new Integer(updateCount));

Probably I could re-code both cases differently to minimize memory usage,
but data in the case a) will be garbage collected on the next loop, and case
b) will be garbage collected after the method call (if application ignores
the values there).

But I haven't run it in the profiler, so maybe there is something more which
I have missed. Can you check this with some memory profiler?

Roman