I am getting very confused here..
There are 4 types of JDBC driver:
JDBC-ODBC Bridge Driver (Type 1)
JDBC-Native API (Type 2)
JDBC-Net pure Java (Type 3)
Native-protocol, pure Java driver (Type 4)
But if you search on the web for the fastest JDBC driver, the answer is:
JDBC Net pure Java driver (Type 4)
Isnt't JDBC-Net pure Java the type 3 driver? Why the answer put JDBC-Net pure Java and type 4 together? Thanks a lot!
Your confusion stems from the fact that none of those names are the official names, the official names as defined in the JDBC specification are simply "Type n" with n is 1, 2, 3 or 4. It looks like your unnamed sources tried to attach a summarizing name to the types, and those names just leads to confusion because your different sources used different names for the types.
The JDBC 4.3 specification defines the types as:
9.1 Types of Drivers
There are many possible implementations of JDBC drivers. These
implementations are categorized as follows:
Type 1 — drivers that implement the JDBC API as a mapping to another data access API, such as ODBC. Drivers of this type are generally
dependent on a native library, which limits their portability. The
JDBC-ODBC Bridge driver is an example of a Type 1 driver.
Type 2 — drivers that are written partly in the Java programming language and partly in native code. These drivers use a native client
library specific to the data source to which they connect. Again,
because of the native code, their portability is limited.
Type 3 — drivers that use a pure Java client and communicate with a middleware server using a database-independent protocol. The
middleware server then communicates the client’s requests to the data
source.
Type 4 — drivers that are pure Java often using a network protocol or File I/O to communicate with a specific data source. The client
connects directly to the data source.
None of those types is necessarily the fastest. Given the lack of overhead from going from java code to native code and back, Type 4 drivers are likely the fastest for the same database system. Type 3 will likely be the slowest, because you go from your Java code to a remote middleware server that will then translate to a database specific protocol (possibly using another JDBC driver!) to the actual database. In my experience, type 3 drivers are very rare.
As a counter-example of Type 4 being the fastest, I maintain Jaybird, the JDBC driver for Firebird. Jaybird provides a Type 4 and two Type 2 implementations (one that uses the native client library to connect to remote Firebird servers, and one that offers Firebird Embedded inside your Java process).
In general its Type 4 driver is the fastest for localhost and remote connections, the Jaybird Type 2 'Embedded' driver is usually the fastest overall as that will host the database server in the Java process, foregoing the overhead of the network or inter-process communication. However in that situation using a Type 4 driver is not even possible (using Firebird Embedded requires loading and talking to a native library) so that is a false comparison.
The Jaybird Type 2 'native' driver is usually on par or slightly slower than the Jaybird Type 4, but it might be faster for connections to a Firebird server on the same host as it might use a slightly faster IPC protocol instead of TCP/IP for certain connection strings, if the host is Windows.
Informing your decision purely on 'which type is the fastest' is useless anyway, as some database vendors only offer a Type 4, or a Type 2 and a Type 4, while for example Type 1 is pretty much dead since Oracle dropped the JDBC-ODBC bridge from Java. Type 3 is pretty rare, so you're unlikely to find it anyway.
In general, if available, I recommend choosing Type 4, because it usually has the least hassle (eg Type 2 requires correctly installing the native library, configuring your application to find the native library, etc). However, sometimes a Type 2 driver might offer features not otherwise available (like Firebird Embedded).
Related
I'm actually working in a situation where a .NET stack is managing an Oracle Database. Now, because the legacy code is consistently based on PL SQL stored procedures that deal with the majority of the work, the correct choice of driver to connect to the database is of primary importance.
For this reason, knowing that Oracle provides a large number of driver for the most known programming languages, I was trying to find a documented benchmark (even with all the problem and the influence of the context in which the tests are made) that could compare the different Oracle drivers for the different programming languages, just to support the hypothesis that the best choice in terms of performance for an isolated test microservice would be to use the Java driver in combination with Scala (Java is now property of Oracle now, after all).
Are there any on the internet that could support (or not) this hypothesis?
EDIT
I didn’t provide all the information. What I’m trying to achieve is develop a series of microservices focused on fetching data from the database and convert them into json to be consumed by the front end. .NET driver behaves seamlessly until the numbers become really overwhelming (> 1000 rows).
That’s why I was wondering if it could make any sense using JDBC to increase performance, having heard that, for instance, .NET driver for SQL server, both made by the same Company, performs 5 times better than the oracle one when it comes to gathering data from a cursor.
Your choice of drives may not give you the milage if most of the work is in PL/SQL or stored procedures. Having said that, jdbc is a good choice. However do not fight if developers are more familiar with other drivers like Oracle ODBC, oracle provider for .NET, ADO,etc.. all protocols have a Oracle drive to access Oracle DB.
You don’t have to convert to json. Oracle DB can convert it. Your network latency is more impacted by how big the pipe is ,array size,and packet size than protocols.
I have an idea to write an application to work with SAP Sybase IQ16 server using Go language. Platform windows/nix does not matter yet. I had workewd with this database using C# later, and I remember, that there was no ADO.NET driver, so I used ODBC + iAnywhere.Data.SQLAnywhere.v4.0.dll to establish connection. Also, I know, that drivers for IQ, ASE, etc... are not compatible. I looked here https://github.com/golang/go/wiki/SQLDrivers, but neither оf drivers seems to be compatible. Thus, I can not understand at all is there solution for my problem.
I was looking here:
http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28395/toc.htm
but everything looks like C or C++. Can I use any other language to use the OCI?
Thanks.
EDIT: I need to use direct path for LOB object (blob, clob, etc.) I believe I have to use the OCI to do that.
EDIT: I base my OCI assumption on this: Can a direct path insert into a LOB column?
According to Oracle
"Oracle Call Interface (OCI) is the most comprehensive, high
performance, native 'C' language based interface to the Oracle
Database that exposes the full power of the Oracle Database."
However, there are different ways to work with an Oracle database. What sort of language do you want to use, and what do you actually want to achieve?
If you want to use Java, you can use JDBC OCI. I believe that there are also ways to acess OCI through Perl, Python, and Ruby, if you want (though I've never used them).
Theoretically, every language that can call standard C functions should be able to use OCI. This includes languages such as C++ and Delphi, but also includes managed languages such as C# (that can access these functions through P/Invoke) or Java (with Java Native Interface).
However, if your goal is simply to access the Oracle, but don't care to do it specifically through OCI, it is much better to use whatever library is specifically geared towards your language of choice. For example, use ADO.NET under C# or JDBC under Java.
Most of these libraries use OCI internally anyway (with notable exception of some direct-to-wire ADO.NET and JDBC drivers).
You will find that most Oracle APIs in other languages are really bindings to the OCI using whatever mechanism that language normally uses to interoperate with C libraries. Examples include cx_Oracle for Python, OCI*ML for OCaml and Oratcl. These typically abstract the OCI which is very low level, into something easier to use from a high-level langauage (e.g. connecting to a database is one line in those langauges, but it is a page of code in OCI as everything must be set up explicitly).
can anyone tell me How does jdbc work? How it manages to communicate with a DBMS? since DBMS may be written with some other programming language.
Communication with the database is handled by JDBC drivers that can use various strategies to "talk" to a database (from "translation" to the use of "native" language). Depending on the strategy used, drivers are categorized into 4 types. Types of JDBC technology drivers provide a good description of each of them:
A JDBC-ODBC bridge provides JDBC API access via one or more ODBC
drivers. Note that some ODBC native
code and in many cases native database
client code must be loaded on each
client machine that uses this type of
driver. Hence, this kind of driver is
generally most appropriate when
automatic installation and downloading
of a Java technology application is
not important. For information on the
JDBC-ODBC bridge driver provided by
Sun, see JDBC-ODBC Bridge Driver.
A native-API partly Java technology-enabled driver converts
JDBC calls into calls on the client
API for Oracle, Sybase, Informix, DB2,
or other DBMS. Note that, like the
bridge driver, this style of driver
requires that some binary code be
loaded on each client machine.
A net-protocol fully Java technology-enabled driver translates
JDBC API calls into a DBMS-independent
net protocol which is then translated
to a DBMS protocol by a server. This
net server middleware is able to
connect all of its Java
technology-based clients to many
different databases. The specific
protocol used depends on the vendor.
In general, this is the most flexible
JDBC API alternative. It is likely
that all vendors of this solution will
provide products suitable for Intranet
use. In order for these products to
also support Internet access they must
handle the additional requirements for
security, access through firewalls,
etc., that the Web imposes. Several
vendors are adding JDBC
technology-based drivers to their
existing database middleware products.
A native-protocol fully Java technology-enabled driver converts
JDBC technology calls into the network
protocol used by DBMSs directly. This
allows a direct call from the client
machine to the DBMS server and is a
practical solution for Intranet
access. Since many of these protocols
are proprietary the database vendors
themselves will be the primary source
for this style of driver. Several
database vendors have these in
progress.
As we can see, there are various strategies to make interoperability possible, including implementing the network protocol used by a given database in Java (type 4). And because of their ease of use (no extra stuff to install, no JNI) and their good performances (they perform as well as type 2 drivers now), type 4 are actually the most frequently used nowadays.
From Wikipedia:
JDBC drivers are client-side adapters (installed on the client
machine, not on the server) that convert requests from Java programs
to a protocol that the DBMS can understand. [edit] Types
There are commercial and free drivers available for most relational
database servers. These drivers fall into one of the following types:
Type 1 that calls native code of the locally available ODBC driver.
Type 2 that calls database vendor native library on a client side. This code then talks to database over network.
Type 3, the pure-java driver that talks with the server-side middleware that then talks to database
Type 4, the pure-java driver that uses database native protocol
Most database systems support ODBC (Open Database Connectivity or whatever). This is meant to allow applications (e.g., Access) to work with multiple RDBMS implementations at the cost of some performance hit. When JDBC was first released, there was a driver that allowed you to connect to an ODBC provider. Later on, some vendors provided JDBC drivers specific to their RDMS.
From a developer's perspective, JDBC is used as a set of interfaces. All the actual details are hidden in loading the driver. The driver is a Java class that can use any trick of the book, including native code or just sending network traffic to the RDBMS.
From Wikipedia:
JDBC is an API for the Java programming language that defines how a client may access a database. It provides methods for querying and updating data in a database. JDBC is oriented towards relational databases.
JDBC was first introduced in the Java 2 Platform, Standard Edition, version 1.1 (J2SE), together with a reference implementation JDBC-to-ODBC bridge, enabling connections to any ODBC-accessible data source in the JVM host environment.
Without going into too much detail, you can think of JDBC as an abstraction layer that lets you talk to different databases. The implementation-specific details are hidden from you, but the interface for querying a database (be it MySQL or Oracle or whatever) is the same.
What this means is that in future, if there was a new database, someone only needs to use the existing interface. The method names would be the same, but the methods would contain implementation-specific code for that particular database. This is a common software-engineering pattern.
The entity that contains the implementation-specific code is called the JDBC driver. The JDBC driver provides a connection to the database and it also implements the specific protocol for sending the query to the database and the result-set back to the client.
Can't say I know the exact answer to your question, but here is some information to help.
Here's a great place to start:
http://java.sun.com/products/jdbc/overview.html
The JDBC API contains two major sets of interfaces: the first is the JDBC API for application writers, and the second is the lower-level JDBC driver API for driver writers.
Information for JDBC Driver Developers. Basically there are a set of interfaces that a developer implements to create a JDBC driver for a particular DBMS.
http://java.sun.com/products/jdbc/driverdevs.html
As far as a DBMS being written in a different language. That DBMS most likely exposes some API (in various languages and/or formats) that allow for drivers, such as JDBC, to communicate with the DBMS.
From the wikipedia page:
Types
There are commercial and free drivers available for most relational database servers. These drivers fall into one of the following types:
Type 1 that calls native code of the locally available ODBC driver.
Type 2 that calls database vendor native library on a client side. This code then talks to database over network.
Type 3, the pure-java driver that talks with the server-side middleware that then talks to database
Type 4, the pure-java driver that uses database native protocol
Reading a bit about the four types of JDBC drivers might enlighten you.
i am looking for an Delphi component to connect to an ORACLE database server in an direct way without install the oracle client.
i knew the Oracle Data Access (ODAC) from DevArt. there are any other component with this capability?
ODAC offers two connection modes to
the Oracle server: connection through
the Oracle Call Interface in Client
mode and direct connection over TCP/IP
in Direct mode. ODAC-based database
applications are easy to deploy, do
not require installation of other data
provider layers.
Thanks in advance.
No, there is no other Delphi Win32 libraries allowing to connect to Oracle without the installed Oracle Client. And, IMHO, that is correct, because:
OCI (Oracle Call Interface) is quite complex piece of software. I will say, it is most complex closed sourced DBMS Call Level Interface in the World. And it is changing from version to version. Oracle has official rule - the Oracle Client v X supports Oracle Server v X-1 ... X+1. Because even such company as Oracle, dont want to spend resources to support and test all the protocol nuances across all possible versions. So, I dont think, that DevArt ever will implement 99.9% stable Oracle SQL*Net protocol implementation. And the INet posts proof that ...
AFAIK, the ODAC Net mode does not support some of the Oracle Client important features and has some important limitations. Although it works well for simple data access scenarious.
If you will purchase Oracle support, then it will decline all your support requests, if they will know, that you are not using official client software. That is just Oracle rule.
If you dislike to install and tune the full scale Oracle Client, then you can just use Oracle Instant Client. Which does not require install or setup procedure. And you will be in safety in case of the different data access scenarious and Oracle Server versions.
PS: Although I may be considered as a biased person :)
There is also Allround Automations Direct Oracle Access, it do require Oracle SQL*Net or Net8. but is a brilliant component suite.
The only solution I found is ODAC, and it's working very nice, I have been using it since years without getting any problem with the direct mode.
there's some limitation with the direct mode, but most of users will not get these limitations with their application.