Hi,

I just thought I would report on a discovery I made regarding the type 2
driver modifications I made available. As the stand the binaries I made
available will not show any performance improvement on a local connection -
they will show a slight performance degredation.

I was looking at the possibility of using java 1.4s java.nio.ByteBuffer in
direct mode to reduce the amount of copying done mapping the XSQLDA
structure to native code(which has come along very well) when I found I
could not reproduce my original benchmarks using the type 2 driver.

A lttile head scratching later I remembered that while doing these tests the
database path name was hard coded into the dll as somthing like
"c:\database.fdb". The version I released builds this from the url and ends
up somthing like loopback/3050:c:\database.fdb. I realised that having the
loopback/3050 on the front seems too(for abvious reasons) make use of TCP/IP
while removing this it seems to use some kind of local ipc. My twice as fast
inserts came back when I hard coded "c:\database.fdb" back in.

So if anyone has tried the type 2 driver modifications and was disapointed
with the performance improvments this will be why. I will make avaiilable
binaries soon that fix this along with over-synchronization and a resource
leak on exception handling that was present in the last binaries I made
available.

I've got some modifications comming together that make use of
java.nio.DirectBuffer so that the java XSQLDA acts as a peer for a native
XSQLDA. As data is written to a prepared statement for instance, it gets
written dirctly to the underlying XSQLDA structure which eventually is
passed to the interbase api.

So far it's zero copy(other then the copying of the variable to the XSQLVAR
of course) for writing variables ( all but blob and non one byte per char
strings ) to prepared statements. I intend to complete this to also be zero
copy for reading from a result set and make propper use of the client
libraries fetch buffer - and use the java.nio.DirectBuffer for ferrying blob
segments into and out of interbases c api.

This has required encapsulating further the XSQLDA structure and kindof
moving responsibility for encoding and decoding to this( so for instance I
can use java.nio.ByteBuffer.setLong to a long to a XSQLVAR in a single
call). Hopefully though through this expermimenation I will be able to
re-apply these changes reasonably quickly and neatly once the release branch
is made and make them available for review. This should eventually give us a
higly efficent type 2 driver implementation.


Thanks
Ryan