When using setBinaryStream(int, InputStream, int) with batch execution, the rows in the second batch (and the following) contain an empty BLOB.
The rows in the first batch get correctly inserted.
All rows get correctly inserted when not using batch execution.
In Jaybird 2.1.6 this didn't work at all: setting a blob in a batch resulted in a FBDriverNotCapableException (for both test1 and test2)
org.firebirdsql.jdbc.FBDriverNotCapableException: Not yet implemented.
Thanks for the clear testcase, it made finding the cause relatively easy. There are two bugs involved.
The first problem is that a copy of the blob id of the last blob created in the previous batch execution stays behind in one of the internal structures. When adding parameters for the second and third batch this actually causes Jaybird to ignore the InputStream, and copy the last inserted blob from the server back to the client.
The second bug occurs when making that copy: Jaybird does not update a length variable (it is initially 0), so on execute of the batch it creates a new blob of 0 bytes.
If it weren't for the second bug Jaybird would actually have created copies from the last inserted blob of the previous batch execution, ignoring the data of the provided InputStream.
Workaround: Call setNull(1, Types.BLOB) on the prepared statement (where 1 is the index of the parameter to set) before setting the inputstream, this will remove the blobid from the internal structure.