Re: PreparedStatement parameters and mutable objects

Oliver,

I think we are free to do it either way. I suspect that most jdbc
drivers delay this work until the actual call to the server.

I am curious why you are choosing to optimize this particular aspect?
It seems the bigger win is on query results where the common code path
does the following: read from socket, put value into a new byte[],
convert byte[] to a String, convert String to required object/type.
There are three copies in different forms of the same data being
generated for each value. Ugh!

I have long wanted to fix this, but it always ends up being too big a
project for the time I have to work on it. Have you given any thought
to this bigger problem?

Also, your email below indicates to me that you are trying to do this
with the old V2 protocol methods of executing queries. The new V3
protocol provides a much, much better interface to the driver to do this
more efficiently. Have you looked at using the V3 protocol features to
execute the prepared statements?

thanks,
--Barry

Oliver Jowett wrote:

> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>