| Subject | Re: [IB-Architect] RE: Architecture of interclient |
|---|---|
| Author | Mark O'Donohue |
| Post date | 2001-02-22T15:09:11Z |
Hi Jim
Jim Starkey wrote:
implementation on the client side all the way down to the protocol used
on the wire to the server. Basically a rewrite of all client software,
and talk directly to the 3050 socket. This would be a type 4 driver,
and wouldn't have the performance hit of going through another server
layer. - but is from what I understand dificult to do here.
The type 3 drivers have a java client talking to another server which
passes the info onto the real server (aka interserver/interclient).
This has all the discussed overheads, but at least provides a 100% java
solution for the client, which in some circumstances (like you don't
want to really have to do anything on the mac except have people tell
you the code runs) is desirable. But the type 4 has obvious advantages
over the type 3 ones, in terms of speed. and for that reason is ones
java developers like to have around.
The type 2 drivers are what you have which is a java layer which uses
JNI to talk to a local native library which then talks to the server.
(Hmm... buggered if I can remember what a type I library is, perhaps
i've got my numbers wrong somewhere here)
I've used/compiled and sent a few bug fixes to the FreeTDS jdbc layer
which provides a type 4 interface to the MSSQL/Sybase TDS wire protocol
and have used it in a production system replacing a replication engine
between MSSQL and Oracle (Oracle also have type jdbc 4 libraries). The
program runs on a Solaris box and/or win32 box (depending upon whim of
the administrators) and was developed partly on a linux box. I say this
just to show how useful when your working in java not being dependant on
any native code can be.
As you pointed out often peak performance is not the main issue, but
just the fact that it works at all, and for client programs it's often
handy.
I don't mind having a type 2 driver with better performance, but I would
always prefer to have a type 4 driver hanging around because the
marketting people always tend to put their head in asking if we can
supports clients running on the amiga/sgi irix/commodore64/hp3000/palm
pilot/netBSD platform.
interserver socket communications?
I though most of the java socket stuff translated fairly directly into C
code, the interclient <-> interserver code I haven't looked too closely at.
I did wonder why, if they were going to all that trouble, that Borland
didn't write interserver in java with a few JNI calls to the C
interface. This would have simplified the communications layer between
interserver and interclient to a few socket.writeObject(xxx) calls,
(possibly passing it through a compression filter or even now an SSL
filter). But like I said I haven't looked at it in too much detail yet.
way down to the 3050 socket writes.
situations where I was doing c++ things, it was always difficult to pull
support for the required client platform out of a hat, and I can see a
similar thing happening if there is any native component in a client
side install.
the java classes. It sounds good, for the C++ people and it's possible
that from that a pure java type 3 driver could be created fairly
easily. That would be creating an "interserver" (although please! let's
not call it that) replacement built on your current type 2 jdbc
interface, which provides a java server socket listener handling
requests from the 100% java clients.
Thinking about it, there is a simple way of doing this with the Proxy
class that came out in 1.3. You use the Proxy class to forward requests
to an interface over a socket to the server. Actually I already have
the code since I have done exactly that for an upgrade of a recent program.
(Hmm ... I started writing about how I got to the Proxy class, but it
turned into a history of how I've been working with generating c++/java
object infrastructures from tables for years. In particularly
infrastructures that use generic SQL and a runtime switchable interface
to talk to many different backend databases including to remote internet
servers over sockets (inetd things), It turned into another essay so I
cut it)
Needless to say that it is possible to write a fairly simple set of java
wrapper classes using the Proxy object that will expose your current
java jdbc api on a remote machine. Since performance is not always the
only objective but is an important one it would be interesting to see
how such a system would perform relative to the current interclient
program. (Currenly my simple implemtation returns the whole rowset, but
with with the newer jdbc stuff, where each row is now serialisable you
could easily do it one or a few rows at a time).
have is that at least the source has been released into the public
domain ;-). I don't begrudge you getting paid for what you do, I think
its quite reasonable, particlarly given the circumstances that it all
went belly up, but I suspect at current rates of uptake, that your odbc
driver still has quite a way to go before it will be released. And I
presume the jdbc component would also take some time.
If we junk interclient, we need to either write a replacement or get one
from somewhere, what you've got sounds like a nice alternative to start
with, but its not something we currently have available. So tinkering
with interserver/interclient , is something we can do now, even it over
time we replace the whole thing, and will at least give a working option
throughout the process.
Of course if someone wins tattslotto in the near future, or makes a
killing at blackjack that could change.
I think I called MAC's lava lamps after one particular fan referred to
my linux machines as sh** boxes.
Although I havent had to use them even though we ended up with a few MAC
users (thanks to my 100% java coding ;-). I always though that although
Steve Jobs seemed to take design to a degree you can only describe as a
fetish (he's still keen to get computers into a cube) that at least they
were designed, and not the unholy tangled mess that windows has evolved
into.
Cheers
Mark
--
Your database needs YOU!
http://firebird.sourceforge.net
Jim Starkey wrote:
> At 10:00 AM 2/22/01 +1100, Mark O'Donohue wrote:The optimal solution (for the java world) is to have a java
>
>> Actually I would say that not having a 100% java client solution (even
>> if other options are available) misses the point of using java.
>>
>
> The user written Java code is, as it should be, isolated from
> the implementation. Casual database use probably doesn't care
> about performance, and the security hit of passing all passwords
> and data through an extra server probably isn't that bad.
implementation on the client side all the way down to the protocol used
on the wire to the server. Basically a rewrite of all client software,
and talk directly to the 3050 socket. This would be a type 4 driver,
and wouldn't have the performance hit of going through another server
layer. - but is from what I understand dificult to do here.
The type 3 drivers have a java client talking to another server which
passes the info onto the real server (aka interserver/interclient).
This has all the discussed overheads, but at least provides a 100% java
solution for the client, which in some circumstances (like you don't
want to really have to do anything on the mac except have people tell
you the code runs) is desirable. But the type 4 has obvious advantages
over the type 3 ones, in terms of speed. and for that reason is ones
java developers like to have around.
The type 2 drivers are what you have which is a java layer which uses
JNI to talk to a local native library which then talks to the server.
(Hmm... buggered if I can remember what a type I library is, perhaps
i've got my numbers wrong somewhere here)
I've used/compiled and sent a few bug fixes to the FreeTDS jdbc layer
which provides a type 4 interface to the MSSQL/Sybase TDS wire protocol
and have used it in a production system replacing a replication engine
between MSSQL and Oracle (Oracle also have type jdbc 4 libraries). The
program runs on a Solaris box and/or win32 box (depending upon whim of
the administrators) and was developed partly on a linux box. I say this
just to show how useful when your working in java not being dependant on
any native code can be.
As you pointed out often peak performance is not the main issue, but
just the fact that it works at all, and for client programs it's often
handy.
I don't mind having a type 2 driver with better performance, but I would
always prefer to have a type 4 driver hanging around because the
marketting people always tend to put their head in asking if we can
supports clients running on the amiga/sgi irix/commodore64/hp3000/palm
pilot/netBSD platform.
> IfSorry do you mean java socket code, or borland interclient <->
> you have ever looked at the implementation of the lower layers
> of Java communication code, take a look. It's not pretty and
> it's not fast.
interserver socket communications?
I though most of the java socket stuff translated fairly directly into C
code, the interclient <-> interserver code I haven't looked too closely at.
I did wonder why, if they were going to all that trouble, that Borland
didn't write interserver in java with a few JNI calls to the C
interface. This would have simplified the communications layer between
interserver and interclient to a few socket.writeObject(xxx) calls,
(possibly passing it through a compression filter or even now an SSL
filter). But like I said I haven't looked at it in too much detail yet.
>Which is why the best java solution is to have the client java all the
> But if somebody wants to use Java in a production environment,
> the issues aren't so simple. An intermediate server doubles
> the network traffic, adds latency, and (unkind generalization on
> Borland's communication implementations omitted).
way down to the 3050 socket writes.
>Sorry, that was a bit confusing on my part, I just meant that in a other
>> An entirely java client reduces problems of install/transporting across
>> various client platforms to zero. Running on a mac client for instance
>> only then requires the JVM (same for Solaris, Linux, FreeBSD, etc).
>> I've used this approach with Oracle and with MSSQL... and FB/IB using
>> interclient. Problems I've previously had with say ODBC client
>> libraries just go away.
>>
>
> We're not talking about ODBC.
situations where I was doing c++ things, it was always difficult to pull
support for the required client platform out of a hat, and I can see a
similar thing happening if there is any native component in a client
side install.
> We talking about a JNI solution toIt sounds interesting, I assume you provide C (or C++) api's that mirror
> map JDBC semantics directly on the Firebird API. And maybe supplanting
> the legacy API in the process.
>
> Installation should involve sticking two additional platform specific
> dynamic libraries in a system directory (a JNI native library and the
> Firebird/jdbc layer). No other configuration should be necessary.
the java classes. It sounds good, for the C++ people and it's possible
that from that a pure java type 3 driver could be created fairly
easily. That would be creating an "interserver" (although please! let's
not call it that) replacement built on your current type 2 jdbc
interface, which provides a java server socket listener handling
requests from the 100% java clients.
Thinking about it, there is a simple way of doing this with the Proxy
class that came out in 1.3. You use the Proxy class to forward requests
to an interface over a socket to the server. Actually I already have
the code since I have done exactly that for an upgrade of a recent program.
(Hmm ... I started writing about how I got to the Proxy class, but it
turned into a history of how I've been working with generating c++/java
object infrastructures from tables for years. In particularly
infrastructures that use generic SQL and a runtime switchable interface
to talk to many different backend databases including to remote internet
servers over sockets (inetd things), It turned into another essay so I
cut it)
Needless to say that it is possible to write a fairly simple set of java
wrapper classes using the Proxy object that will expose your current
java jdbc api on a remote machine. Since performance is not always the
only objective but is an important one it would be interesting to see
how such a system would perform relative to the current interclient
program. (Currenly my simple implemtation returns the whole rowset, but
with with the newer jdbc stuff, where each row is now serialisable you
could easily do it one or a few rows at a time).
>[ I hope I've now explained this above, in creating a type 4 driver ]
>> The performance penalty seems to be mainly in the extra layering (in
>> interclient anyway).
>
>> [snip]
>
>
> Is you argument that it has to be slow because other drivers are
> slow?
>
> I don't understand what any additional code needs to be written
> in Java (not that I have any objection to Java code).
>Which leads us into another issue, One advantage that interclient does
> I'm not suggestion anyone rewrite, re-architecture, or
> re-implement interserver. I'm merely suggesting that we
> junk it.
have is that at least the source has been released into the public
domain ;-). I don't begrudge you getting paid for what you do, I think
its quite reasonable, particlarly given the circumstances that it all
went belly up, but I suspect at current rates of uptake, that your odbc
driver still has quite a way to go before it will be released. And I
presume the jdbc component would also take some time.
If we junk interclient, we need to either write a replacement or get one
from somewhere, what you've got sounds like a nice alternative to start
with, but its not something we currently have available. So tinkering
with interserver/interclient , is something we can do now, even it over
time we replace the whole thing, and will at least give a working option
throughout the process.
Of course if someone wins tattslotto in the near future, or makes a
killing at blackjack that could change.
>[snip - a few unkind remarks about MAC paparatzi]
I think I called MAC's lava lamps after one particular fan referred to
my linux machines as sh** boxes.
Although I havent had to use them even though we ended up with a few MAC
users (thanks to my 100% java coding ;-). I always though that although
Steve Jobs seemed to take design to a degree you can only describe as a
fetish (he's still keen to get computers into a cube) that at least they
were designed, and not the unholy tangled mess that windows has evolved
into.
Cheers
Mark
--
Your database needs YOU!
http://firebird.sourceforge.net