Oliver,
while I think the code snippet below has defined behaviour I think it is
fraught with danger.
As long as everyone knows that the code does this and writes code that
does not break then yes it would work, however I don't believe this is
the case.
Also reading the spec that you provided, I think the phrase "when it
sends" refers to the actual conversion that takes place not the specific
time that it is done.
In general while I can see that this would indeed speed up the driver, I
don't think I can agree to the mechanism proposed however, I'm willing
to be convinced.
Dave
On Tue, 2004-01-06 at 20:05, 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
>
--
Dave Cramer
519 939 0336
ICQ # 1467551
