Reference | Help | Introduction | Slide Show | Class Hierarchy | InterClient
PREV | NEXT | FRAMES | NO FRAMES |  |

# 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.

Reference | Help | Introduction | Slide Show | Class Hierarchy | InterClient
PREV | NEXT | FRAMES | NO FRAMES |  |

Send comments or suggestions to interclient@interbase.com