D.2.h ( Talk) [InterClient Java Technology For InterBase]

InterClient Java Technology For InterBase

InterClient Java Technology For InterBase from a talk prepared in July 98 by Paul Ostler for BorCon 98

What is JDBC?

· Core Java API As a core java , jdbc is in every java virtual machine. So jdbc applications are byte- code portable across java platforms and . As the lowest level java database access api, it forms the basis of all higher level relational database . Jdbc is ubiquitous. · Call Level Interface (CLI) Buzzwords that mean it adheres to the x/open and iso standards for cli database access. Odbc is also based on cli. So jdbc can be thought of as the java analog of odbc, but there are some important architectural differences in that many jdbc drivers are distributed and designed with the network in mind, odbc drivers are usually not distributed and rely on the dbms client library for network access and other client-side functionality. · Low level but easy to use Jdbc is at the same level of database access as odbc, namely cli, but jdbc is much easier to use than odbc mostly because it's a java api. In jdbc, both memory management and data byte alignment are handled for you. If you're an odbc or dsql programmer you know about managing data memory areas, or for dsql, managing descriptor areas for your dynamic queries. And unless you're allocating memory off the heap for every column separately, you need to make sure that column data is aligned on proper byte boundaries. As a java library, java manages object memory for you, there's no need to surface these low level details to the user at the level of the api. · Base API As a core api, jdbc is used universally by · Web browsers where the jdbc driver lives transparently on the net. · Desktop applications where jdbc is used for local database access. · Application servers for n-tier applications; jdbc is in the middle-tier, and the application could use corba or rmi based communication. · Client/Server applications for 2-tier applications, jdbc is used for direct database access from client to server. · High level APIs such as Enterprise Java Beans for server based components, Java Blend object-relational mapping, JDX object-relational mapping, JDBTools for replication, Embedded SQL (SQLJ) preprocessor to jdbc. The acceptance of java server technology means jdbc will be used on every tier, and is the universal backend for database access. So Where's the Beef?

Jdbc sounds great, so why aren't more people using java and jdbc now for industrial applications? "Putting App Servers to the Test," PC Week Labs Report, June 22, 1998 · "We found Java VMs and Java database drivers just aren't ready for the demands of high- load, production environments." An article from JavaWorld suggests four issues that must be resolved before Java can succeed: "Are you ready for the Java backlash?", JavaWorld, August, 1998 · When will Java performance (particularly on the server) be acceptable? Most database drivers are slow too. · When will the reliability of the language and the JVM be acceptable? Some flakey JVM ports have been released. JavaSoft has put a lot of effort into rolling out new APIs quickly, but often at the expense of reliability of the APIs. · When will there be a standard Java upon which major development efforts can depend? When will Bill Gates say uncle?

· Is Java ready to be a major database language? Curious, this was an article about java, not database, but this was included. It's interesting that database may be holding up acceptance of Java! Ok, having played the devil's advocate, I believe these problems are being solved rapidly. InterClient is ready for commercial use, and we'll make a few comparisons with other drivers a little later. But before we can talk about the last issue "Is Java ready to be a major database language?", we need to understand JDBC architectures... ODBC Driver Architecture

An ODBC driver is a bridge from the ODBC API to the DBMS API. DBMS client library provides client/server A DBMS protocol is a communication protocol between the DBMS client and the DBMS server, it should not be confused with a low level network protocol such as TCP/IP. It regulates data exchange, control of transactions, and the like. So the DBMS client library drives the network messaging protocol which controls the server. This includes issues of pipelining, prefetching rows, two phase commit, event handling, managing database object handles, synchronizing cursor and transaction state with the server, blob streaming, and many other tasks. ODBC is a api, and is therefore somewhat platform dependent. Recompilation is necessary, as well as porting of any non-standardized system calls. Here's some example dbms client libraries you may have heard of: Oracle oci, or Sybase dbLib, or InterBase isc. The network messaging protocol for Sybase is known as Tabular Data Stream (TDS), and the DBMS Remote Layer might be Sybase Open Server. BDE Architecture

BDE/SQLLinks is a bridge to the DBMS client library BDE is more componentized that ODBC because it defers the database dependencies to SQL Links. So there are separate SQL Links drivers for each database, but only one BDE. DBMS client library provides client/server The BDE also provides higher level functionality than ODBC, such as dataset caching. BDE is a C api and runs only on Windows. Class 1 JDBC Driver Architecture

There are 4 classes of jdbc drivers, class 1 and 2 are similar to your traditional driver architecture. A class 1 driver is a bridge from the JDBC API to the ODBC API. Both jdbc and odbc are based on cli, so this mapping is a natural, and allows Java applications to access a database with existing odbc support. JavaSoft provides this jdbc-odbc bridge as part of the jdk. There is only one jdbc-odbc bridge, but there is a separate odbc driver for each database. DBMS client library provides client/server Jdbc is a java api, and the bridge is written in java; odbc is a c api, and an odbc driver is written in C. So the jdbc-odbc bridge is what i call a language driver; the semantic difference between odbc and jdbc is minimal, the main difference is the language barrier. So this same kind of architecture could be used by other language drivers, eg. a perl to odbc bridge. Class 2 JDBC Driver Architecture

A class 2 driver is a bridge from the JDBC API to the DBMS API. Similar to class 1 except we're bridging directly to the database's native C client library rather than to odbc. So the closer the client library is to cli, the more amenable it is for the driver. DBMS client library provides client/server We're still a language driver, because we're still bridging from java to c. The jdbc driver is in java, and the dbms client library is in C. This is the most common architecture for language drivers, eg. IBPerl, written by our very own Bill Karwin, has this architecture. Although interclient, which is a class 3 driver, is faster than class 2 drivers. In general, class 2 drivers are the the fastest class of drivers because they use the native C libraries and protocols which have been around a while and have been finely tuned. So why is a class 2 driver architecture not the best architecture for java drivers? Well, it turns out there's a problem with this architecture on the Java platform... Distributed Drivers

Just to review, bridges provide a mapping to an underlying database API, and don't have client/server functionality directly, rather bridges rely on the underlying client libraries for client/server functionality. · So what's the problem with bridges in the Java platform? It basically boils down to java's interpreted byte-code capabilities, security sandbox, and zero-install clients. · Applet security One of the biggest strengths of java is its portable byte code without recompilation. Java was designed for the network. Java byte code can float the network, be downloaded dynamically, and execute within the context of a security sandbox. But if the java code makes C calls, the underlying C routine runs outside the security sandbox, so the java verifier has no choice but to assume the code is insecure. · Preinstalled client libraries This entails your traditional client maintenance, configuration and installation of C libraries. And a pre-installed client library defeats the purpose of network capable applets. · Portability Java is cross platform without recompilation. C is not interpreted so requires recompilation across platforms, and ANSI C is a language, not a platform, and does not attempt to standardize system libraries as java does.

· So what's the solution? No more C on the client! This means, put the entire database client functionality into an embeddable all java driver! Class 3 JDBC Driver Architecture

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. Class 4 JDBC Driver Architecture

The final class of distributed driver is still an all java client, but the jdbc client library implements the exact same protocol as that used by the C client library. Now, the interbase server can't tell the difference between a java client and a C client. So you remove the need for a separate jdbc server. All client components are pure Java Driver subsumes DBMS client library and protocol

Class 4 · Reuse existing remote layer for both C and Java clients

· But pinned to legacy protocol which may not be amenable for jdbc access Class 3 · More flexible More flexible architecture since you have complete control over the server side; no legacy protocol issues; streamlined for jdbc.

· But requires a new remote server In addition to the interbase server, there is now a jdbc server that must be started on the server or middle tier. C clients and Java clients use different remote layers. Another advantage of the class 3 architecture is that it's tiered, with the jdbc server in the middle tier. This adds flexibility for things like security, compression, and underlying data marshalling. If you look at sybase which has a class 4 driver, no sybase server remote layer currently supports SSL, so if you want data security using jConnect, you have to go thru an intermediary HTTPS gateway. Because interserver is tailored specifically for interbase remote access, to say interserver is a driver component, or a dbms component is rather arbitrary. But it is clear that interserver and its remote protocol are shrink wrapped tightly around the interbase native api and interbase capabilities. This flexibility gives rise to the fastest jdbc driver on the market today, interclient. Ok, I've talked about streamlining a class 3 jdbc protocol for jdbc access. Here's an example of how the remote protocol can be tailored for jdbc. In jdbc, there is no start transaction method, rather transactions are started implicitly on the first SQL statement execution. So in a well designed jdbc net protocol, there is no START_TRANSACTION opcode, rather the server side transaction is started when the first SQL statement is executed. However, most dbms vendor protocols have an explicit START_TRANSACTION opcode. This is one extra message that must be sent and acknowledged on the wire that would be unnecessary in a class 3 jdbc client library. Drivers Tested

· JDK 1.1 ODBC Bridge/InterBase 5 Uses the InterBase net protocol thru ODBC. · InterClient 1.50/InterBase 5 Uses a JDBC net protocol to ISC gateway (InterServer). · jConnect 4/SQLAnywhere 5 Uses the Tabular Data Stream (TDS) net protocol. · DataGateway Broker 1.0/InterBase 5 Uses a JDBC net protocol to BDE gateway. DG version which ships with JBuilder 2. · DataGateway Bridge 0.73/InterBase 5 Uses the InterBase net protocol thru BDE. DG version which ships with JBuilder 2. · dbANYWHERE 1.1a/SQLAnywhere 5 Uses a JDBC net protocol to ODBC gateway. · Driver X/Server X (not Oracle) Purported [by a newsgroup poster] to be the fastest JDBC driver. Driver Performance

These tests use straightforward jdbc code using driver defaults. There are no optimizations or adaptations for interclient. Performance Demo

There are 2 files you'll need to run these tests. PerformanceTests.java is a driver independent suite of tests. ExampleTests.java calls into the PerformanceTests class, passing specific drivers for testing, and specifies which tests to run. Both source files are located in the interclient distribution in the examples directory. These tests not only demonstrate the performance of various drivers, but also demonstrate the portability of jdbc code across dbms's despite the great architectural differences between jdbc drivers. · examples/ExampleTests.java · examples/PerformanceTests.java Tiered Application Architecture

Ok, we've covered driver architecture, now let's look at application architecture. Two Tier Architecture Three Tier Architecture

The 2-tier architecture is your traditional client/server application architecture, it doesn't matter what class jdbc driver architecture you're using, that's irrelevant. A 3-tier architecture is a term usually applied to an application architecture. But the term may also be applied to driver architectures as well. The documentation for class 3 drivers will describe their driver architecture as 3-tier, but the usual meaning of the term is a 3-tier application architecture that is independent of the architecture of jdbc driver used. We've seen how to distribute the driver into client/server components, now a tiered application architecture distributes the application itself into client and server components. The middle tier maintains control over access and updates to your corporate data. A tiered architecture is more secure. The application server regulates access to data according to business rules and application requirements. The client application could be an applet, that's irrelevant. The communication between the client application and the application server involves high level requests, not jdbc requests. And the protocol used between client application and application server is not defined - it could be CORBA or RMI (both RPCs) and is usually RPC-based, but it could also be a message based protocol. So there's two kinds of middleware in the 3-tier model, the application middleware to the middle tier, and the database middleware to the 3rd tier. In turn, for each of these middlewares, there are 2 kinds of distributed communication protocols: RPC based or message based. The application middleware could be RPC-based or message-based, but the database middleware is almost always message based for efficiency reasons. The message protocol for database middleware is vendor specific, based on proprietary protocols, and is hidden from the application layers. The application server may employ enterprise java beans (a component model for the server), or CORBA objects. The default communication protocol between distributed enterprise java beans is RMI, but Sun is currently working on RMI over IIOP so that RMI will be CORBA compatible. RPCs vs. MOMs

From Java World, May 1998, "Write your own MOM"

RPCs - language call model, blocks MOMs - event model, non-blocking All RPCs are based on the concept of using remote procedure calls or methods as though they were local. So if a client wants to send a request for service to a remote machine, the client simply invokes a method. RPCs include RMI and CORBA as well as your traditional non-object oriented RPCs. CORBA provides a language independent RPC as well as other services. Message-oriented middleware doesn't model network requests on method calls. Rather, messages are sent and received in an event model. So under the RPC model, a client invokes a remote method and waits for it to return. But under a MOM (Message Oriented Middleware), a client sends a message and is then free to do as it wills asynchronously. This accomodates pipelining, and asynchronous event handling. Message passing is non-blocking. Most distributed drivers are message oriented, eg. the datagateway broker, and interclient/interserver, but there is at least one jdbc driver i'm aware of that uses RPCs, it's called RmiJdbc. A DBMS message-based communication protocol is proprietary, and allows for efficient row prefetching, blob streaming, etc... that would not be possible using synchronous RPCs. MOMs are becoming very popular in Java because of their flexibility and performance. JavaSoft has recently released for public review an enterprise api for message based middleware known as JMS (Java Messaging Service). RPCs have the advantage of ease of use; modelling requests as method invocations gives good programming language integration. But often the setup requirements for ORBs and other RPC based systems is extensive. Tiered Application Architecture - CORBA

For a final look at database application architecture, let's look at your typical CORBA application of the future. I say future, because the JDBC-XA specification has not yet been released. XA is an X/Open distributed transaction specification and an XA enabled driver will allow an ORB to control transactions across heterogeneous data sources, even non-jdbc data sources, using a transaction manager known as the java transaction service (JTS) which manages your xa resources. JTS is a specification from javasoft that is one of the upcoming enterprise apis in the java extension packages, and is a java mapping of the OMG standard for an Object Transaction Service (OTS). Visibroker has its own integrated object transaction service which is operational today. This same architecture could be used with enterprise java beans communicating via RMI rather than using an orb. Enterprise java beans is a server-side component model, or beans for the middle and server tiers. CORBA uses a language-neutral RPC based communication protocol, but there's considerable setup managing your client stubs and IDLs, as well as maintaining your ORB. Enterprise Java Beans (EJBs) will be compatible with CORBA. JDBC Basics

Ok, let's leave architecture behind and talk about the jdbc api. Simply put, ... JDBC is an interface (API) for · Connecting to databases · Submitting commands · Processing results A jdbc driver provides the code to support the jdbc interfaces Basic JDBC interfaces are · java.sql.Connection · java.sql.Statement · java.sql.ResultSet These interfaces are implemented by a driver. Getting a Connection

DriverManager is a connection factory and in turn a connection is a factory for database meta data. The driver manager is the starting point for a jdbc application. The application must first register the jdbc drivers it wishes to use with the jdbc driver manager, which maintains a list of registered drivers. This will change in jdbc 2 where the application is freed from having to determine the drivers it will need. Once the necessary drivers are registered, an application can get a connection by calling DriverManager.getConnection() with a database URL, username, password, and connection properties. The driver manager will use the jdbc driver that's appropriate for the particular database URL, and return a connection established using that driver. Jdbc is a dynamic api, so once you get a connection to a database, you can query the database meta data which describes jdbc driver capabilities, database engine capabilities, and database schema such as columns, tables, stored procedures, etc.. See examples/FirstExample.java Submitting SQL

For databases that support statement precompilation, good drivers will precompile prepared statements on the server prior to statement execution. This allows greater performance for repeated statement executions. Prepared statements also support input parameters which are usually supplied repetitively for multiple statement executions. The jdbc specification does not require that prepared statements be precompiled in order not to exclude compliant drivers for databases which do not supported prepared statements. Callable statements are statements which are used exclusively for stored procedure statement executions, and support OUT parameters in addition to a result set. See examples/FirstExample.java Retrieving Results

Since jdbc supports dynamic query execution, result set meta data can be extracted to describe the columns of a result set. Notice that meta data must be extracted from an actual result set in jdbc 1. In jdbc 2, and interclient 1.50, result set meta data can be extracted from a prepared statement before statement execution. See examples/FirstExample.java {link to FirstExample.txt} Using a Driver Extension

Most drivers support extensions in support of unique features of the underlying dbms See examples/FirstExample.java JDBC Interfaces Summary

Interface Description

Driver Connection factory

Database session; Statement factory This is a database session; a session is a sequence of transactions - but they're not Connecti concurrent or nested. While the connection is active, there can be one and only active on transaction with periodic commits or rollbacks, but no nested transactions and no distributed transactions in jdbc 1.

Databas eMetaDa Database info for a Connection (tables, indices, capabilities, field types, etc...) ta

Stateme SQL container; ResultSet factory nt

Prepare dStatem Precompiled SQL; possibly parameterized ent

Callable Stateme Stored procedure nt

Cursor for results of query ResultSe You can think of a result set as a SQL cursor, it's not a container which holds results t by itself. A result set has no persistence by itself, it's not serializable and you can't just save it to disk. jdbc 2 provides a new object called a rowset for this purpose.

ResultSe tMetaDa Column information for a ResultSet ta Using InterClient with JBuilder

Building components with InterClient Feature Overview

· Full JDBC support InterClient may be the most fully functional jdbc driver available. Here's some information found in the release notes of other jdbc drivers: · With dbAnywhere to sql server (now called adaptive server) a statement with a result set must either be explicitly closed or the result set exhausted before it can be reused. This is a limitation enforced by the DbLIB client libraries to process all of the results before issuing another SQL request. · Also with dbAnywhere, ResultSet.getBytes() is not supported to Sybase/MS sql server. · dbANYWHERE does not support DATE and TIME literals, escape characters in LIKE clauses are not supported, outer join escape syntax is not supported. · Using jConnect for SQL Server you cannot use the following DatabaseMetaData methods on a connection in the middle of a transaction: getColumns(), getColumnPrivileges(), getTablePrivileges(), getPrimaryKeys(),getCrossReference(),getIndexInfo(). So if autocommit is off, you can't precede any of these methods with uncommitted SQL execution! This is because these methods create temporary tables using CREATE TABLE which is not allowed within a multi-statement transaction in SQL Server. · outer join escape syntax is not supported for SQL Server. · row counts (from executeUpdate) are not available for SQL Anywhere. · stored procedures in SQL Anywhere cannot return both result sets and output parameters, they can return only one or the other. · setAutoCommit off didn't work in SQLAnywhere prior to 5.5.

· Reliability and ease of use InterClient is easy to configure and use. Compare with Sybase jConnect in which procedures must be installed on the server in advance before database meta data can be accessed. · Internationalization We support 20 of the 22 interbase character sets for direct transliterations into interbase. Data is transliterated to the character set of choice, generally using the native locale- specific encoding of the user. This provides much better performance than drivers that use only a single universal encoding on the wire. Interclient is completely localized, with easily translatable resource bundles for all error messages and hard-wired text used by the driver. · Extensions We currently have extensions for describing input meta data (ParameterMetaData), as well as the ability to retrieve result set meta data before a prepared statement is executed. Support for features unique to interbase are forthcoming. · High performance. Leverages the flexibility of a class 3 driver, and shrink-wrapped around InterBase. · Pure Java Fully portable zero-config/zero-install client.

· Well ported JDBC server Most JDBC servers work only on Windows Multitier configuration Service may be proxied to any interbase server thru an interserver middle tier. Feature Demos · Online API documenation · Show SQLExplorer · Show Swingset · Explorer tour What's Coming?

· Administration Server connections, connection properties, etc... We're also extending our C client library with new runtime administration capabilities. · Endemic InterBase features Events, roles, commit-retain, and some new interbase sql features in the pipe are sql dates, times, and timestamps, exact numerics, quoted delimiters, etc... · JDBC 2 core API Currently in beta release in the jdk 1.2.

· JDBC 2 extension API This will live in the java extension package javax.sql along with many of the other new enterprise apis. To be released for public review summer 98. JDBC 2 Core

Specification released for public review June, 1998. Download from http://java.sun.com/jdbc The jdbc 2 core api was released for public review on june 1, 1998. As well as providing new database functionality, one of the goals of jdbc 2 is to leverage the new java technology which was released subsequently to jdbc 1. jdbc 1 was released with the jdk 1.0, and did not integrate with the new technology released in jdk 1.1 and 1.2. When jdbc 1 was released, there was no java beans component model. Under the java beans component model, a jdbc 2 rowset (part of jdbc 2 extension api) will be a serializable java bean. Jdbc 2 core will make use of the new internationalization features of the jdk 1.1. Think of the new jdbc 2 java.sql package as a superset of the old jdbc 1 java.sql package. So jdbc 1 applications will continue to work under jdk 1.2, but they'll require new jdbc 2 drivers which support the new java.sql interfaces in jdk 1.2. InterClient will provide a driver for jdk 1.2, jdbc 2 methods which are not yet implemented will throw a SQLException. Because of widely disparate capabilities of various dbms, almost everything new in jdbc 2 is optional. Due to public review and beta use of the jdbc 2 core api as part of the jdk 1.2 beta, some new interface methods will be added in the final release which do not currently appear in the downloadable jdbc 2 specification as of today, August 30, 1998. · Advanced datatypes Required for compliance. Blob and Clobs and Array support from SQL3. We're currently working on the Array support. · User defined types This is optional for compliance as it relies on object engine capabilities. The jdbc 2 designers invision 3 kinds of jdbc drivers/databases in the future. Those that support SQL 3 user defined structured types and refs, or those that support persistent storage of Java objects (aka extended relational system), or those that support the traditional SQL 2 relational model. I won't venture into this political arena, but it may be that if you want to store objects, you should either use an object relational mapping, or you should use a pure java object oriented database. · Performance hints User directed performance hints to the driver. setFetchSize(int numRows) tells the driver how many rows to prefetch and cache on the client. When a result set is created, a suggestion can be made to the driver as to the intended direction of traversal, eg. forward only. Drivers are allowed to ignore these suggestions, but interclient won't. We've already implemented the setFetchSize() method. · Batched updates This will yield huge performance improvements, especially when working over the network. This is a way to roll up, or batch up, a set of pending update statements into a single server request to be sent over the network. So a batched update may consist of several update, delete or insert statements heterogeneously which can all be sent as a single request to the server. Batched updates also allows for multiple inputs to a single prepared statement to be sent all at once to the server. In jdbc 1, each new set of inputs results in a separate request for a prepared statement execution which would have to be relayed over the network to the server. This is purely driver functionality requiring no new support from the engine. InterClient will incorporate this in a future release. · Result set enhancements This includes scrollable cursors and updatable result sets. Scrollable cursors is optional for compliance but according to the jdbc designers at javasoft, this is the most requested feature. Scrollable cursors support relative and absolute positioning, forwards and backwards movement thru a result set. Scrollable cursors will require significant driver and engine support. Much work has already been done in InterBase towards engine- capable scrollable cursors, as well as work in the remote interface and the InterBase C client library. Once supported, InterClient will plug into InterBase's engine-capable scrollable cursors, and provide its own remote interface in the pure java client library. There are two basic kinds of results sets - scrollable or forward only. And there are two basic kinds of scrollable result sets - sensitive and insensitive [cursors]. Sensitive result sets are sensitive to changes made by other transactions, insensitive result sets are not even sensitive to changes made within their own transaction. Sensitive result sets may not sense all changes if setFetchSize() is greater than 1 because of client-side row caching by the driver. refreshRows() has been added recently to jdbc 2 to allow for sensitivity to row changes that might not otherwise be seen in a client cached row. Updatable result sets will be supported using either database write locks or an optimistic concurrency scheme in which, when rows are updated, the old row values are compared to current values in the database to determine if an update conflict has occurred. The optimistic concurrency algorithm is provided within the driver, not requiring database locks, and can in fact allow for disconnected rowset capability for mobile computing. Read only result sets will also be supported New ways of doing positioned updates and deletes, which was not well supported in jdbc 1 and not universally supported by drivers. · Character streaming The facilities for streaming characters didn't exist in the jdk 1.0 when jdbc 1 was released. JDBC 2 Standard Extension API

Specification to be released for public review Summer 98 Still in javasoft partner review, but should be released soon for public review. More advanced than core api, and generally depends on modules provided by the other java extension apis, especially enterprise java beans. The java extension interfaces exist in the suite of javax packages, so for example, the jdbc 2 standard extension interfaces exists in package javax.sql, the enterprise transaction interfaces exist in package javax.transaction. The javax packages will be employeed extensively by enterprise java beans. Enterprise java beans is a server-side component model, whereas java beans are a client-side component model. Each one of these is a major topic in itself but i've prepared a brief overview for each topic. · Rowsets If you think of a result set as a cursor, then think of a rowset as a self-contained collection of rows, disconnected from a database connection. So rowsets are always scrollable, and even more important, a rowset may be serialized to disk. That is, a rowset is a serializable java bean. A rowset can be used while disconnected from the database. A rowset is a container for tabular data that's updatable and serializable and can even be moved around the network independently from any database connection. As tabular self- contained data, a rowset can even come from non-SQL data sources. No locks are maintained by the database; when changes need to be propagated back to the database, an optimistic concurrency algorithm is used which ensures the original values of the rowset were not changed while the rowset was disconnected from the database. If changes to the original database values represented by a rowset do occur, an update conflict is issued and nothing is updated. Think of a rowset as a disconnected, serializable, updatable self contained java bean for tabular data. As a java bean, it can be stored to disk at will and restored at will, and be used at design time in a visual builder. Rowsets also allow multiple cursors on its data. But the main difference from a result set is that for a rowset, all of it's rows are completely cached, so it exists independently from the database. Not all rowsets are updatable, many dbms vendors are unable to dynamically determine the table from which a result column originated, so the jdbc 2 specification doesn't require joins to be updatable, some of which could be. InterClient will support updates on rowsets created thru joins provided a unique row identifier is selected for each joined table. · Connection pooling The idea behind connection pooling is to reuse database connections. This is important when there are many connections coming and going regularly from a client. When a connection is closed, rather than just closing the physical connection to the database, the connection can be put into a connection pool for possible reuse by another client, or another thread wishing to establish a connection to the same database. How long it remains in the pool depends on your pooling algorithm. A driver can implement its own pool, but it's only aware of its own connections, so it can only pool connections created by that driver. But there could be several drivers on the client, with heterogenous data sources. So jdbc 2 will include a pooling module that will sit on top of jdbc, and manage a collective pool so to speak for all jdbc drivers on the client. So each driver will implement certain hooks that allow the pooling module to get at its pooled connections, and the driver will notify the pooling module on top of jdbc whenever it is finished with a connection. Sun provides the interfaces for the connection pooling module which resides on top of jdbc, but does not provide an implementation. Pooling modules will be provided by 3rd party vendors, and they'll probably be integrated with transaction servers. Pooling modules are meant to be used by enterprise java beans. · XA distributed transactions This is a two phase commit protocol implemented underneath of the XA resources interface. This is similarly architecturally to connection pooling, in that any one particular driver can only be aware of its own connections in a distributed transaction, so to allow for heterogeneous data sources, there are hooks that must be implemented by each driver, and a transaction module, aka java transaction service (JTS), sits on top of jdbc. The hooks that need to be implemented are essentially two-phase commit. So the driver implements the two phase commit protocol with methods such as prepare, commit, abort which operate across multiple connections. Please note that this is driver functionality. Two-phase commit is implemented in the client library. InterClient implements its own client library and cannot rely on the two-phase commit protocol implemented in the InterBase C client library. Like connection pooling, a driver's implementatoin of two phase commit only allows it to manage distributed connections within the driver itself. The transaction module, which is known as a java transaction service, allows distributed transactions which span multiple drivers or even non-jdbc data sources! So the JTS can coordinate activities across heterogeneous data sources. The JTS is a standard java mapping of the OMG Object Transaction Service (OTS) which is meant to be used by a CORBA orb for managing transactions. So interclient-xa can be used either by CORBA distributed transactions or by Enterprise Java Beans. Visibroker has its own integrated transaction service. The enterprise java beans component architecture allows a server bean to perform distributed transactions seamlessly across heterogenous data sources using a JTS. The enterprise java beans themselves will be able to communicate either using RMI or RMI over IIOP so that enterprise java beans can fully interoperate with CORBA applications. This technology is expected to be released for early access this summer as a java standard extension. · JNDI name service support InterClient will support the Java Naming and Directory Interface as an alternative way of naming databases to the standard jdbc 1 database url naming conventions. With the current methods in jdbc 1, an application has to explicitly load any particular drivers it may need (eg. Class.forName()), and when an application needs to get a connection, it has to specify a jdbc subprotocol which is also specific to a particular driver (eg. jdbc:interbase:). The idea with JNDI is to free the application from having to make these decisions, and put the information about what driver should be used with what database into some kind of naming service repository. So a database could be moved from one machine to the next, and only the name repository would have to change, not the application. The JNDI is simply an interface that interclient will plug into for accessing directory service information provided by some JNDI service provider implementation such as LDAP. I'm not sure what the format of the data stored will be, but it should provide for driver independence, at least in the jdbc application. The naming service will attach a particular driver to use for a particular database, and there will be some kind of logical name associated with the database. Notice that a name service provides a server-side registry of databases, rather than the client-side aliases we're used to from ODBC and BDE. A jndi url would be something like "jdbc:interbase:jndi:LDAP_hostname:port_number/...". The jndi service provider implementation could use an LDAP server (lightweight directory access protocol). A Few Performance Hints

I've started to collect a few performance hints. If you have any more please mail them to me, and maybe we'll publish this along with the rest of our documentation sometime in the future. · Use VARCHAR for large text fields CHAR strings are fixed length and not compressed by the current interclient remote protocol.

· Use StringBuffers when concatenating large strings · Use the interbase.interclient.Adaptor when stepping thru Date/Times. · Use Statement.setFetchSize() · Use stored procedures for lots of inserts Use prepared statements for repeated executions of SQL, possibly parameterized

Thanks for coming. Enjoy the conference and Colorado!

· InterClient · http://www.interbase.com/jdev · [email protected] · JDBC · http://java.sun.com/products/jdbc · Enterprise JavaBeans · http://java.sun.com/products/ejb · Java Transaction Service · http://java.sun.com/products/jts · Java RMI over IIOP · ftp://ftp.omg.org/pub/docs/orbos/98-03-08.pdf