Re: JDBC Interface for Embedded Server ?

[Mark Matthews]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Shankar Unni wrote:
> Nigel Wetters writes:
> 
> 
>>slarty2 probably had the right idea when he suggested that
>>to be any faster, a lot of the driver should be written 
>>in C, whereas my efforts were a very thin layer of C with 
>>a thick layer of java.
> 
> 
> The main key is to stay out of the JNI *interface* as much as possible.
> JNI is fairly inefficient - the stepping between C and Java is a fairly
> heavyweight operation.
> 
> If it's possible to structure the driver such that lightweight calls
> (e.g. ResultSet.next(), ResultSet.get*(), etc.,) are all in pure Java,
> and you only go to C for the actual execute() or other calls that need
> to talk to the DB, you might be in good shape.
> 
> It'll be interesting to see what performance improvement you get..

Which is basically what Connector/J does. Performance will be similar, 
only because you are going to spend a lot of time converting between the 
'C' strings in libmysqld and the Java Strings, which Connector/J has to 
do, but without allocating extra memory to do it.

There is a good chance you will have problems on some JVMs getting 
libmysqld to work as well, because Sun has changed some of the semantics 
of various C-library calls for I/O so that they work from Java threads.

I think your best bet performance wise (and quickest to develop) would 
be to make something like the MySQLIO class in Connector/J support 
libmysqld, and issue commands/build result sets at that point, and leave 
the rest up to the existing JDBC driver code.

As an aside, most of the top-performing JDBC drivers across the RDBMS 
industry are actually Type-IV (100% pure Java) because of the overhead 
in calling through JNI that a Type-II driver (part Java, part native) 
needs to do. Some of the Type-III drivers (100% Java client, net 
protocol to native library bridge) are pretty fast too, but that is a 
similar situation to the one you describe, because all of the JDBC stuff 
is done in 100% Java, and they use an optimized network protocol to talk 
to a middleware driver that does coarse-grained operations against the 
native DB library.

	-Mark
- -- 
MySQL 2003 Users Conference -> http://www.mysql.com/events/uc2003/

For technical support contracts, visit https://order.mysql.com/?ref=mmma

     __  ___     ___ ____  __
    /  |/  /_ __/ __/ __ \/ /  Mark Matthews <mark@stripped>
   / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Full-Time Developer - JDBC/Java
  /_/  /_/\_, /___/\___\_\___/ Flossmoor (Chicago), IL USA
         <___/ www.mysql.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.1.90 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+RpV/tvXNTca6JD8RAplwAKCFm1hLEQEgpH0WJtTaOJfiitYiOgCgxnj6
QpFI2Sb74IoIYmxK8LKekAk=
=Wpdr
-----END PGP SIGNATURE-----