In a simple jdbc example , when we load a driver through a java class, the practise is to use Class.forName("com.mysql.jdbc.Driver").newInstance();
Why we do not use new com.mysql.jdbc.Driver();?
This piece of code isn't really intended to create an instance of the driver but to ensure the driver class is loaded by the class loader. Nowadays this is no longer needed, see:
What is the actual use of Class.forName("oracle.jdbc.driver.OracleDriver") while connecting to a database?
JDBC Class.forName vs DriverManager.registerDriver
Loading JDBC driver
What is the purpose of 'Class.forName("MY_JDBC_DRIVER")'?
JDBC connection- Class.forName vs Class.forName().newInstance?
Related
I have a standalone 3rd party application working with Oracle database and I need to troubleshoot its DB queries. And I don't have access to its source code (nor desire to decompile it :-) ).
Its DB connection configuration has several separate parameters:
Driver: oracle.jdbc.OracleDriver
JDBC URL: jdbc:oracle:thin:#localhost:1521:orcl
User name & password
But I can't change driver as application is checking for a list of supported drivers and just refuse to start if I put com.p6spy.engine.spy.P6SpyDriver into the driver parameter.
So can p6spy still be used in this case? If not, is there any other way to trace application DB access from application's end (I'm aware of Oracle tracing, that would be my next step if this won't work)?
Many thanks!
You can use P6Spy in Datasource way
The question I have is why does Oracle SQL developer does not require Oracle client installed on local?? I searched on the internet and found that it makes use of JDBC thin driver. Can someone please throw some light on this topic?
The Oracle thin driver is a so-called JDBC Type 4 driver, which is implemented purely in Java without native dependencies (.dll/.so), and has a full implementation of the Oracle wire protocol. In other words the thin driver does not require the Oracle client installed, as it doesn't use it.
There are also JDBC Type 2 drivers which do use native dependencies; Oracle has a Type 2 driver as well which is known as the Oracle JDBC OCI driver. This driver uses a JDBC url that is prefixed with jdbc:oracle:oci:.
The Type 1 and Type 3 drivers I ignore because they are hardly relevant these days.
Without load Driver Class.forName("com.mysql.jdbc.Driver") my program
work is fine... How...?
This is explained in the javadoc of DriverManager
The DriverManager methods getConnection and getDrivers have been enhanced to support the Java Standard Edition Service Provider mechanism. JDBC 4.0 Drivers must include the file META-INF/services/java.sql.Driver. This file contains the name of the JDBC drivers implementation of java.sql.Driver. For example, to load the my.sql.Driver class, the META-INF/services/java.sql.Driver file would contain the entry:
my.sql.Driver
Applications no longer need to explicitly load JDBC drivers using Class.forName(). Existing programs which currently load JDBC drivers using Class.forName() will continue to work without modification.
When the method getConnection is called, the DriverManager will attempt to locate a suitable driver from amongst those loaded at initialization and those loaded explicitly using the same classloader as the current applet or application.
What is the combination of driver and jdbc URL to use for CDH5 (I am on CDH5.3)?
I have tried a few including:
jdbc:hive2://myserver:21050/;auth=noSasl
And with the following driver:
org.apache.hive.jdbc.HiveDriver
I have added
/opt/cloudera/parcels/CDH/lib/impala/lib/*:/opt/cloudera/parcels/CDH/lib/hive/lib/*
to the classpath (but still no success)
The result is:
java.sql.SQLException: No suitable driver found for jdbc:hive2://myserver:20150/;auth=noSasl
Firstly, make sure you're using the correct driver. You should use the Impala JDBC driver (rather than the Hive driver).
Then you should be able to use the com.cloudera.impala.jdbc3.Driver driver with a connection string like: jdbc:impala://host:21050
The Impala JDBC driver guide has more details and examples.
Our java applications will access legacy mainframe db2 databases.
I remember in my previous projects, C++ applications required db2 binding before deployment.
In current projects, all mainframe applications, Cobol packages are also required to do db2 binding.
Does a java application that uses jdbc4 driver needs db2 binding too?
If you are using standard JDBC you are creating dynamic SQL (PrepareStatement) that do not requires binding in DB2 side.
However, if you use SQLj, you will need to 'precompile' that code to generate you .java files and another file to bind in the database.
It does not matter if you are connecting to a mainframe (system z or i) or to a DB2 LUW. The concept is the same for all platforms as DB2 is DB2.
SQLj is not very popular, however is very powerful to tune your queries and improve the data access, however, as you used to do in C, the code has to be developped in more phases, and you have to rebind each time the access plan has to be modified (new statisques, security, etc.)
SQLj is very easy to use from Data Studio, and SQLj from DB2 is not exactly the same from Oracle.
The JDBC type IV driver, supplied by IBM, will handle everything you need to do.
The driver maps Java objects into DB2 appropriately.
I don't know what "binding" means in this context. Java is not C++.
If your DB2 version supports Dynamic Statement Caching and enabled (consult your DBA’s), you can use JDBC Type-4 driver to access mainframe DB2 database (use prepare statement) without binding.
DB2 will generate access paths and store it in first request into cache. Otherwise, you need use SQLJ like technologies and bind them.