Issue Details (XML | Word | Printable)

Key: JDBC-312
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Mark Rotteveel
Reporter: A Drouard
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.
Jaybird JCA/JDBC Driver

Batch insert with setBinaryStream inserts an empty BLOB

Created: 22/May/13 03:22 PM   Updated: 08/Dec/13 09:47 PM
Component/s: JDBC driver
Affects Version/s: Jaybird 2.2, Jaybird 2.2.1, Jaybird 2.2.2, Jaybird 2.2.3
Fix Version/s: Jaybird 2.2.4, Jaybird 3.0.0

File Attachments: 1. Java Source File (5 kB)

Windows 7
JDK 1.7
Firebird 2.5

 Description  « Hide
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.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
A Drouard added a comment - 22/May/13 03:28 PM
JUNIT test case
test1 : one batch of 10 inserts OK
test2 : insert with no batch OK
test3 : three batch of 10 inserts KO

Mark Rotteveel added a comment - 22/May/13 05:51 PM
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.
at org.firebirdsql.jdbc.field.FBBlobField.getCachedObject(
at org.firebirdsql.jdbc.AbstractPreparedStatement.addBatch(
at nl.lawinegevaar.fb.jdbc312.TestBlobWriting.insert(
at nl.lawinegevaar.fb.jdbc312.TestBlobWriting.test1(

Mark Rotteveel added a comment - 22/May/13 06:41 PM
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.

I will fix this for Jaybird 2.2.4 (and 2.3).

Mark Rotteveel added a comment - 22/May/13 06:47 PM - edited
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.

Mark Rotteveel added a comment - 28/May/13 07:13 PM
Fixed in Branch_2_2, trunk (2.3) to be done

Mark Rotteveel added a comment - 28/May/13 09:13 PM
Also fixed in trunk