Hi,

>> I have seen that the XNET protocol aims to solve this problem.
>
>Yes, it was clearly stated in firebird-devel list that we will have
>XNET protocol in FB 1.5. Also we will have embedded version of FB 1.5,
>so I think this should be our target.

I was just looking at some posts in firebird-devel list regarding this. The
thread is called 'XNET status update'. The initial post was -

>Just to let you know that the code of XNET has been significantly reworked.
>Its current version:
>
>a) works ;-)))
>b) doesn't lock parallel attachments
>c) has appr. the same performance as local TCP/IP loopback for single
>attachment
>d) has 10-15% better performance than local TCP/IP loopback for parallel
>attachments (from multiple threads)
>e) doesn't use window messages, hence can work in non-interactive services
>and classic server
>
>It still has some issues that should be solved in the following month.
>
>Since we're very close to FB 1.5 release, this code will be committed into
>the head branch for v1.6.

So perhaps we will not be so lucky as to get this in 1.5. 1.5 shows the same
performance difference for the two different connection string so I assume
its still using the old local ipc method. I dont necesarily disagree that we
should aim for 1.5 and XNET - but if the method of synchronization I'm
trying at the moment(only one thread in native code at one time) is a safe
usage of the FB1.0 client library in local ipc mode - and I can reasonably
cleany support this synchronization along side the synchronized on
db_handle's in the ngds.GDS_Impl class then it would at least be possible to
make use of the local IPC mode as it stands in FB1.0 and possibly FB1.5.

The question would then be how does the client choose which method to use -
using the subprotocol part of the JDBC url as you sugested before could do
this.

So i dont really know what we should do - but a doubling in insert
performance(even if does opperate best in single threaded apps) is 'for me'
tempting.

>> 2) An extension to this set of changes which makes it possible the
>> implement the java XSQLDA object as a peer for the actual native
>> XSQLDA structure using java.nio.ByteBuffer to write/read directly
>> to/from the underlying XSQLDA structure that is supplied to the
>> interbase c api.
>
>We also need a JDK 1.3 compatible version. How are you going to solve
>this issue?

Pre 1.4 and 1.4 vm's that dont support direct ByteBuffer's would fall back
on the existing ngds.XSQLDAImpl. As far as I'm aware the best way to
determin which method to use would be to first check the JNI version in the
native initilize method, and then check that direct byte buffers are
supported. If either of these are false then a value would be returned from
ngds's nativeInitilize that would cause it to fall back.

Using some aspects of the same technique it would be possible to quite
drasticly improve the efficeny of the XSQLDA structure mapping for pre 1.4
releases - but not to the same extent. I dont use pre 1.4 anymore in my work
so this would be of little interest to me. Keeping pre 1.4 working using the
existing stuff would not be a problem.

> much)directly by the ResultSet.getXXX methods to read
> straight from the XSQLDA structure - eliminating much copying that
> occurs.

The exprermental re-factoring I have done maintains an operation jgds
package - it just makes it possible for the gds implementation to have more
control over things allowing it to perform certain operations more
optimally. - so in short: Same as above. (-:

Thanks
Ryan

-----Original Message-----
From: Roman Rokytskyy [mailto:rrokytskyy@...]
Sent: 14 April 2003 17:31
To: Firebird-Java@yahoogroups.com
Subject: [Firebird-Java] Re: Type 2 Driver Modifications - They are
faster honestly.


Ryan,

> I have seen that the XNET protocol aims to solve this problem.

Yes, it was clearly stated in firebird-devel list that we will have
XNET protocol in FB 1.5. Also we will have embedded version of FB 1.5,
so I think this should be our target.

> I see now that I have a few phases of modifications I would like to
> propose - these being:
>
> 1) The original set of changes that intergrate ngds with the driver.
> These lead to very few modifications of code above of the gds
> package.

David, do you think we can apply them before release?

> 2) An extension to this set of changes which makes it possible the
> implement the java XSQLDA object as a peer for the actual native
> XSQLDA structure using java.nio.ByteBuffer to write/read directly
> to/from the underlying XSQLDA structure that is supplied to the
> interbase c api.

We also need a JDK 1.3 compatible version. How are you going to solve
this issue?

> 3) Further modifications above gds which allow the direct ByteBuffer
> method to work as efficently. eg. Having statement fetcher not fetch
> fetchsize of rows but rather fetch size gets passed to the client
> library and each resultset.next call causes a fetch in the
> underlying api - the out_xsqlda of which is used (pretty
> much)directly by the ResultSet.getXXX methods to read
> straight from the XSQLDA structure - eliminating much copying that
> occurs.

Same as above.

Thanks!
Roman



To unsubscribe from this group, send an email to:
Firebird-Java-unsubscribe@yahoogroups.com



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/