Why we cannot use JDBC Type 1 (JDBC-ODBC Bridge driver) and type 2 driver for web application development.
These two drivers requires some client side installation.
I am confused about client ,because when we install all driver specific things in server then what extra things needed for client.
The type I JDBC-ODBC bridge driver is not recommended for production applications. It was a Java 1.0 artifact that allowed immediate interconnection via ODBC for development, nothing more.
Type II JDBC drivers require native code in order to work. It uses the client-side native libraries for your particular relational database. You have to be able to point to those libraries using LD_LIBRARY_PATH or some other environment variable.
You want a type IV JDBC driver, which is 100% pure Java with no client installation needed. All you need is a JAR file in your CLASSPATH.
Why we cannot use JDBC Type 1 (JDBC-ODBC Bridge driver) and type 2 driver for web application development.
There is nothing to prevent anyone from using Type 1 and 2 drivers in a web-application. It is however not recommended (see the third paragraph).
Both Type 1 and Type 2 drivers are not portable across platforms. While this might not appear to be a problem at first glance, it most certainly is. Especially if your unit-tests are run on one platform, and your acceptance testing and production environments are another. Code that appears to succeed on one environment can fail in another.
However, the most important reason for their non-usage in web applications is the presence of native code. Certain failures in native code, will result in JVM crashes, and that is something that is disliked universally. After all, it will result in unnecessary downtime, when a Type 4 driver could have simply dropped the connection and cleaned up after the failure, without affecting the rest of the application.
As far as client-side settings are concerned, usually the client-side installation depends on the type of the driver used. Type 1 drivers actually wrap another database API like ODBC, and hence require the corresponding ODBC driver to setup as well. Type 2 drivers require the DLLs or shared objects to be present in java.library.path, and usually this is done by setting the PATH or LD_LIBRARY_PATH environment variables.
Related
The question that I will ask does not contain any exception or anything. That's where the confusion coming from.
I have been migrating one old legacy application -which connects and writes to Database- to java8. It used to use the db2 library along with the license from /home/db2client/v95fp2/sqllib/java/db2jcc_license_cu.jar:/home/db2client/v95fp2/sqllib/java/db2jcc.jar. And when I check the details of the db2jcc.jar it says IBM DB2 JDBC Universal Driver Architecture.
Now, deleted that library from the classpath and added my new jar under the lib directory of the project db2jcc4-10.5fp11-fp11.jar and deleted the db2jcc_license_cu.jar And when I check the details of the new jar it says IBM Data Server Driver for JDBC and SQLJ. (The reason I changed to the new jar was there was some java8 combability problems in between the old one and java8)
Eventhough I do not have the license and the jars are different, my application still manages to run and write to the database without an exception. This is the reason I am very confused at the moment.
What is the difference between Universal Driver Architecture one and the Data Server Driver for JDBC SQLJ? And why is it still able to run? I have been reading the whole IBM manuals but I still do not know.
I am aware it may not be a type of question that is asked here, but I think that'd help me a lot to understand what's happening.
I am migrating a legacy project to a new server. Previously the project used a Oracle DB but now i want it to use Postgress. The queries are simple enough and work the same in Postgres.
However the project is missing a Postgres jdbc-driver. Can i somehow add this dependency sideways to the jar without recompiling?
Can i somehow add this dependency to the jar without recompiling?
It depends.
If you are running the server as java -jar myserver.jar ..., then you will at least need to modify the manifest in the JAR file. Strictly speaking this doesn't entail recompiling, but you do need to explode, modify and repack the JAR file.
If the server uses Class.forName to explicitly load an Oracle Driver class, then you will need to change that code to load the Postgres Driver class instead. (There are other ways to use JDBC that avoid this, but this depends on how your legacy server is implemented.)
If your server uses Oracle specific database classes, or Oracle specific SQL features (or it needs to do the same in the Postgres world) then more extensive changes will be required.
But without actually examining your codebase in detail, we can't predict what is required.
My advice is to replace the Oracle driver JAR with a Postgres driver JAR, and see what happens when you run your server against a Postgres database with the appropriate schemas and data.
But I wouldn't do this "in production". Do it in a test environment. If you can't set up a suitable test environment ... forget it.
And if you don't have the source code for your server, I would forget it too. If anything goes wrong you will most likely need source code to figure out the problem and fix it.
a quote from java.sql.DriverPropertyInfo javadoc:
The DriverPropertyInfo class is of interest only to advanced programmers who need to interact with a Driver via the method getDriverProperties to discover and supply properties for connections.
Is there an error in the jdbc javadoc since ever? (Cannot believe)
Seems copied from very early versions of jdbc, and even shows up in android environment
I find the method java.sql.Driver.getPropertyInfo, but no method called getDriverProperties
I searched Driver, Connection, DataSource. what am I missing?
This seems to be an error in the documentation. You need to use Driver.getPropertyInfo​(String url, Properties info). Likely the name was changed during development of JDBC 1 and this part of the documentation was missed when renaming (or something like that).
I'll bring it up in the JDBC Expert Group and see if it can be changed in a future JDBC maintenance release. However, as this error has existed for 21 years, it probably won't be a priority.
The DriverPropertyInfo is rather an obscure JDBC feature, and I'm not sure how faithfully drivers implementations update it when adding new properties. I wouldn't rely on it too much.
I'm having a Maven Web Application on a Tomcat 8 connecting to a SQL Server 2012 Database.
For logging purposes I wanted to use the getClientConnectionID.
Due to the policies of Microsoft it's quite a pain to make their driver work with Maven (I know it's possible and I did it for a while, but in my case it lead to several problems after migrating/sharing the project).
Unfortunately the JTDS-Driver refuses to work with the Database server for unknown reasons.
So right now I've just put the sqljdbc4-4.0.jar into the lib folder of Tomcat and the META-INF/services of the project and since then everything is fine.
Yet after doing more with the database I'm unsure if it's worth to switch and tried to get some information what the actual differences between com.microsoft.sqlserver.jdbc.SQLServerConnection and java.sql.Connection are and if it would make sense to change.
So far I couldn't find useful information. Most pages just refer how to solve issues with each type...
Is there any difference in performance, behaviour or other possibilities which would actually justify switching back?
java.sql.Connection is an interface where com.microsoft.sqlserver.jdbc.SQLServerConnection is an implementation for MS-SQL , you can't compare their performance because the first is just an interface that does nothing where the other is the actual implementation. So you use Connection to maintain abstraction in your code, but effectively you will be using the implementation you provide, which is com.microsoft.sqlserver.jdbc.SQLServerConnection in this case. People usually add those as runtime dependencies so they don't get a polluted namespace.
java.sql.Connection is the interface which is implemented by com.microsoft.sqlserver.jdbc.SQLServerConnection.
Normally you would only program against the interface to be independent of the specific implementation. Then - if you don't rely on some implementation specific behaviour - you can simply exchange the jar with the JDBC driver and your code should still work without any changes.
I've been messing around with Apache Derby inside Eclipse. I've booted up a Network Server, and I've been working with servlets. In my Eclipse project, I have a class called "User", inside the package "base.pack". I have an SQL script open, and I've been trying to convert User, which implements Serializable, into a custom type. When I run the following lines, everything works fine:
CREATE TYPE CARTEBLANCHE.bee
EXTERNAL NAME 'base.pack.User'
LANGUAGE JAVA
This follows the general format they identify here: http://db.apache.org/derby/docs/10.7/ref/rrefsqljcreatetype.html#rrefsqljcreatetype
Now, when I try to create a table using this new type, I get an error. I run the following line:
CREATE TABLE CARTEBLANCHE.TestTabel (ID INTEGER NOT NULL, NAME CARTEBLANCHE.bee, PRIMARY KEY(ID));
And I receive the following error:
The class 'base.pack.User' for column 'NAME' does not exist or is inaccessible. This can happen if the class is not public.
Now, the class is in fact public, and as I noted before, it does implement Serializable. I don't think I'm stating the package name incorrectly, but I could be wrong. I'm wondering, is this an issue with my classpath? If so, how would you suggest I fix this? I admit that I do not know much about the classpath.
Thank you.
(For reference, I have configured my project build path to include derby.jar, derbyclient.jar, derbytools.jar, and derbynet.jar, and I have put these files into my project's lib folder as well).
As politely as I can, may I suggest that if you are uncomfortable with Java's CLASSPATH notion, then writing your own custom data types in Derby is likely to be a challenging project?
In the specific case you describe here, one issue that will arise is that your custom Java code has to be available not only to your client application, but also to the Derby Network Server, which means you will need to be modifying the server's CLASSPATH as well as your application's CLASSPATH.
It's all possible, it's just not a beginner-level project.
To get started with customizing your Derby Network Server, the first topic involves how you are starting it. Here's an overview of the general process: http://db.apache.org/derby/docs/10.11/adminguide/tadmincbdjhhfd.html
Depending on how precisely you are starting the Derby Network Server, you'll possibly be editing the CLASSPATH settting in the startNetworkServer or startNetworkServer.bat script, or you'll be editing the CLASSPATH setting in your own script that you have written to start the server.
If it's a tool like Eclipse or Netbeans which is starting the Derby Network Server, you'll need to dig into the details of that tool to learn more about how to configure its CLASSPATH.
And if you've written a custom Java application to start the Derby Network Server (e.g., as described here: http://db.apache.org/derby/docs/10.11/adminguide/tadminconfig814963.html) then you'd be configuring the CLASSPATH of your custom application.
Regardless, as a basic step, you're going to want to be deploying your custom Java extension classes in the Derby Network Server's classpath, which means you'll want to build them into a .jar file and put that .jar file somewhere that the Derby Network Server has access to, and you'll want to make that build-a-jar-and-copy-it-to-the-right-location process straightforward, so you should integrate it into whatever build tool you're using (Apache Ant?).
And, you'll need to consider Java security policy, because the default security policy will prevent you from trivially loading custom Java classes into your Derby Network Server as that would seem like a malware attack and the Derby Network Server is going to try to prevent that. So study this section of the Security manual: http://db.apache.org/derby/docs/10.11/security/tsecnetservrun.html