| Reference | Help | Introduction | Slide Show | Class Hierarchy | InterClient | ||
| PREV | NEXT | FRAMES | NO FRAMES | ||
A class 3 driver is the first of two distributed solutions.
In this case, the driver is distributed into client
and server components.
All client components are pure Java
Driver subsumes DBMS client library and protocol
The dbms api could either be a server api or a client api. So the jdbc server may reside in a middle tier and is called a gateway if it can proxy service to a remote database server. This could occur if the jdbc server uses a dbms client library.
Besides an all-java client, there's another advantage to this architecture. The jdbc protocol is tailored for jdbc access and control. So the better performance of class 2 drivers is not because of an inherently better architecture, it's because jdbc protocols are newer.
For interbase, the jdbc client library is called interclient, and the jdbc server is called interserver. The dbms api for interserver is isc, the dbms api for datagateway is the bde. Notice that for datagateway, the bde has moved from being a client api to being a server api on the middle tier. Actually, the jdbc client itself could be on a middle tier, and the application on top of it may be an enterprise java bean, this depends on the application architecture, not the driver architecture, but for the time being think of jdbc as being on the client.
For interclient the jdbc server, known as interserver, runs on windows, solaris, hp/ux, and coming soon are linux and sco.
Just as a simple example to demonstrate the difference between a bridge and a distributed driver, consider the driver functionality for ResultSet.next(). A bridge would map next() to isc_dsql_fetch(), whereas a distributed client library would either step thru its local internal cache of rows, or receive a prefetched set of rows off the wire if the internal cache was exhausted.
| Reference | Help | Introduction | Slide Show | Class Hierarchy | InterClient | ||
| PREV | NEXT | FRAMES | NO FRAMES | ||