Type 1 JDBC-to-ODBC Driver The JDBC type 1 driver, also known as the JDBC-ODBC bridge is a database driver implementation that employs the ODBC driver to connect to the database.
The driver converts JDBC method calls into ODBC function calls.
The driver is implemented in the sun.jdbc.odbc.JdbcOdbcDriver class and comes with the Java 2 SDK, Standard Edition.
The driver is platform-dependent as it makes use of ODBC which in turn depends on native libraries of the operating system. Also, using this driver has got other dependencies such as ODBC must be installed on the computer having the driver and the database which is being connected to must support an ODBC driver.
Type 1 is the simplest of all but platform specific i.e only to Microsoft platform.
Type 1 drivers are "bridge" drivers. They use another technology such as Open Database Connectivity (ODBC) to communicate with a database. This is an advantage because ODBC drivers exist for many Relational Database Management System (RDBMS) platforms. + A Type 1 driver needs to have the bridge driver installed and configured before JDBC can be used with it. This can be a serious drawback for a production application.
Can interface to multiple databases - Not vendor specific.
The JDBC Client driver written in java, communicates with a middleware-net-server using a database independent protocol, and then this net server translates this request into database commands for that database.
Thus the client driver to middleware communication is database independent.
Client -> JDBC Driver -> Middleware-Net Server -> Any Database
Since the communication between client and the middleware server is database independent, there is no need for the vendor db library on the client machine. Also the client to middleware need'nt be changed for a new database.
At client side a single driver can handle any database.(It works provided the middlware supports that database)
Requires database-specific coding to be done in the middle tier.
An extra layer added may result in a time-bottleneck. But typically this is overcome by providing efficient middleware
Type 4 drivers are entirely written in Java that communicate directly with a vendor's database. No translation or middleware layers, are required, improving performance.
The driver converts JDBC calls into the vendor-specific database protocol so that client applications can communicate directly with the database server.
Completely implemented in Java to achieve platform independence.
e.g include the widely used Oracle thin driver - oracle.jdbc.driver. OracleDriver which connect to jdbc:oracle:thin URL format.
Client Machine -> Native protocol JDBC Driver -> Database server
Advantages These drivers don't translate the requests into db request to ODBC or pass it to client api for the db, nor do they need a middleware layer for request indirection. Thus the performance is considerably improved.
Disadvantage At client side, a separate driver is needed for each database.
The CallableStatement object is used to used to call a stored procedure.
The CallableStatement object uses 3 types of parameters when calling a stored procedure.
These parameters are IN, OUT and INOUT.
The IN parameter contain any data that needs to be passed to the stored procedure and whose value is assigned using the setxxx() method.
The OUT parameter contain the value returned by the stored procedure. The OUT parameter must be registered using the registerOutParameter() and is retrieved by getxxx() method.
The INOUT parameter is a single parameter is a single parameter is used to both pass information to the stored procedure and retrieve information from a stored procedure.
The registerOutParameter requires 2 parameter. The first parameter is the integer that represents the number of the parameter. The second parameter is the data type of the value returned by the stored procedure.
A transactiobn may consist of many tasks, some of which don’t need to be rolled back should the entire transaction fail.
Ex: Consider order processing. These include
updating the customer account table
inserting the order into the pending order table
sending a customer a confirmation email.
Technically, all 3 tasks must be completed before the transaction is considered completed. suppose the email server is down when the transaction is ready to send the customer a confirmation email. Should the entire transaction be rolled back ? Probably not since it is more important that the order continue to be processed(ie delivered). The confirmation notice can be sent once the email server is back online.
boolean execute() Executes the SQL statement in this PreparedStatement object, which may be any kind of SQL statement.
ResultSet executeQuery() Executes the SQL query in this PreparedStatement object and returns the ResultSet object generated by the query.
int executeUpdate() Executes the SQL statement in this PreparedStatement object, which must be an SQL INSERT, UPDATE or DELETE statement; or an SQL statement that returns nothing, such as a DDL statement.