PreparedStatement parameters and mutable objects - Mailing list pgsql-jdbc

From Oliver Jowett
Subject PreparedStatement parameters and mutable objects
Date
Msg-id 3FFB5B45.80702@opencloud.com
Whole thread Raw
Responses Re: PreparedStatement parameters and mutable objects  (Dave Cramer <pg@fastcrypt.com>)
Re: PreparedStatement parameters and mutable objects  (Barry Lind <blind@xythos.com>)
List pgsql-jdbc
I'm examining ways to reduce the amount of garbage generated by the
driver, and one approach I'm looking at is to delay converting the
parameters of a PreparedStatement to string form until we're actually
streaming data to the backend, to avoid creating an intermediate copy.

This leads to a question .. does this code have well-defined behaviour:

   Connection conn = /* ... */;
   PreparedStatement pstmt =
      conn.prepareStatement("INSERT INTO t(data) VALUES (?)");
   byte[] data = new byte[] { (byte)1, (byte)2, (byte)3 };
   pstmt.setBytes(1, data);
   data[0] = (byte)42;
   pstmt.executeUpdate();

i.e. is the driver required to capture the value of the byte array
passed to setBytes() at a particular time (either the time of the call
or the time of execution), or is it free to choose? Currently we capture
the value at the time of call.

The same problem applies to all parameter-setting methods that take
mutable objects.

I can't see anything about this in the (PDF) JDBC specification. The
javadoc says:

   The driver converts this to an SQL VARBINARY or LONGVARBINARY
   (depending on the argument's size relative to the driver's limits on
   VARBINARY values) when it sends it to the database.

which implies the driver can delay the conversion (or perhaps must delay
the conversion).

Anyone have an opinion on this?

-O

pgsql-jdbc by date:

Previous
From: Kris Jurka
Date:
Subject: Re: odd jdbc driver synchronization issue
Next
From: Dave Cramer
Date:
Subject: Re: PreparedStatement parameters and mutable objects