I have two options to configure my application database connection - one is using JDBC, another one is using JNDI. What will be the best option in terms of how fast those connection types work with the database.
I understand those are two different types of database connections using different principles (JDBC is a direct db connection, JNDI is a database connection pool configuration on application server side). But are there other general JDBC/JNDI pros and cons which might be more important than operating speed? If yes, what are they?
A database connection always uses JDBC. With JNDI you register a datasource in a directory service which can be looked up by its name. Thus JDBC and JNDI are completly different and not interchangeable.
I bet what you mean is choosing from
creating datasource or jdbc connection manually in your application, or
setup the datasource in the container, and application lookup the datasource through JNDI
If it is the case, always stick to 2 if possible.
The main reasons for the choice is never the performance differences. The reason for sticking to 2 is in most cases is, you need 2 to gain more advanced features from container, for example, distributed transaction.
This is what i have found about JNDI and JDBC.
JNDI: This is a technology which works like a telephone directory which is used to search the name on server and datasource remotely.
JNDI creates a connection pool. Connection pool is an environment on the server where JNDI and Database encapsulated to for Type4 connectivity.
JDBC: A Java API that enables Java programs to execute SQL statements.
This allows Java programs to interact with any SQL-compliant database.
JDBC is similar to ODBC, but is designed specifically for Java programs, whereas ODBC is language-independent.
JDBC was developed by Sun Microsystems. JNDI is faster and efficient.
Not totally clear on the question.
JNDI isn't a type of database connection. You can use JNDI to look up a DataSource, which is a factory for connections. The DataSource is part of the JDBC API though, so JNDI works with JDBC as opposed to being alternatives here.
Are you talking about using JDBC against a database for directory information, vs. using JNDI against an LDAP repo?
The real speed benefit comes from being able to reuse database connections.
Hence, you need to use an approach which provides database connection pooling, and then use the appropriate technology to get to the pool. Depending on implementation this can be either JDBC (if the driver supports it itself) or JNDI or something completely different.
If your application runs inside a web container, it is common to use JNDI to allow the pool to be configured and managed in the web container instead of inside your application.
As mentioned in previous answers, using Datasource is the same as using JDBC in terms of technology.
Nevertheless, using a Datasource is usually the preffered way because that way you have the server managing your DB connection pools.
Whether connection pooling is used does not affect application code. It does not require any code changes to the application because the application performs a lookup on a JNDI name of a previously registered data source. If the data source specifies a connection pooling implementation during JNDI registration (as described in section Creating a Data Source Using the DataDirect Connection Pool Manager), the client application benefits from faster connections through connection pooling.
The question is meaningless. Faster at what? There is nothing to compare. JDBC is a general-purpose interface to relational databases. JNDI is a general-purpose interface to naming systems. The strong probability is that the efficiency of either depends 99% on the target system being communicated with. In any case relational databases and naming systems fulfil completely different needs that are largely non-comparable. Usually JNDI is used to obtain a connection, then JDBC is used to operate with that connection.
Related
I am developing a tool that receives different connection parameters to test values in different databases (a plugin for Nagios in jNRPE that keeps an open connection to different databases).
Because the configuration is dynamic (there could be more databases or they can be removed) I cannot have a configuration file.
I want to know if I should have an instance of C3P0 per database or can I use the same instance and just change the URL each time I ask for a connection?
The code is at github:
https://github.com/angoca/db2-jnrpe/blob/master/src/main/java/com/github/angoca/db2_jnrpe/database/pools/c3p0/DBCP_c3p0.java
If not, how can I get multiple pool for multiple databases dynamically?
You'll need a different c3p0 DataSource for each JDBC url. A Connection pool must contain homogeneous Connections: all checked out Connections must be equivalent from a client's perspective. If Connections from multiple databases were included in the same pool, clients would have no way of specifying or knowing which db they were communicating with.
(If you are replicating, say, a read-only DB and you really want Connections from multiple sources to live in a single pool, because they are guaranteed to be equivalent from a client's point of view, you could do that by defining a custom, unpooled DataSource that round-robined or randomly chose a replicant, and then pooling the DataSource via c3p0's DataSources factory.)
It is very easy to dynamically create and configure c3p0 DataSources. See example code here.
If you capture your dynamic config as a map of c3p0 property names to values, there's also an alternative, more concise way to get a DataSource with that configuration.
Question is basically identify the best practices on data access layer.
I want to choose in between using a data source or traditional driver manager to load the the connection on web applications. I know very clearly following advantages
Flexibility of configuration
In built connection pooling mechanism
But if I can sacrifice advantage of flexibility with configuration and have own connection pooling mechanism, Do I get any other benefit out of data source. In other way around what are limitations or issues I would face while having application managed jdbc driver connection than container managed.
I know the question is so stupid that I should be knowing the advantage of somebody takes care of handling connection than my application. But this is rare scenario where I can't use datasource in web application. I would be looking following things
How better I can design own connection pool my self?
Is there any thing else I should take care when I access connection through DriverManager API
Note that is is very possible to programmatically create a DataSource (backed by a connection pool) dynamically based on user input.
Using Apache Commons-dbcp:
BasicDataSource ds = new BasicDataSource();
ds.setDriverClassName(DATABASE_DRIVER_CLASS);
ds.setUsername(DATABASE_USERNAME);
ds.setPassword(DATABASE_PASSWORD);
ds.setUrl(DATABASE_URL);
ds.setInitialSize(1);
ds.setMaxActive(50);
ds.setDefaultAutoCommit(false);
So I think the question is not really between a DataSource and no-DataSource, but rather between a container managed DataSource and an application managed DataSource.
Container managed DataSources are easier to manage by server-admin types. They can be tuned through the app server web UI, etcApplication managed DataSources do not have this advantage.
I am a newbie and I have created a few simlpe Java Swing applications. I was able to use apache commons DBCP to create a connection pool and access the datasource.
I have recently started to create java web based applciations using JSP and Servlets. I have learnt to use JNDI to access the datasource. I update the XML files and use InitialContext() and lookup("java:comp/env") and that is it!!!! I am using Apache Tomcat as my Servlet/JSP container.
1. But where is the DB connection pool created?
2. If yes, then does that mean JNDI somehow uses the DBCP internally?
When I have to create a DBCP for Swing applications, I had to first create an instance of GenericObjectPool and then create a connection factory object and finally a PoolableConnectionFactory object to create the Datasource which will be used to get a connection.
JNDI is a mechanism to pass objects from one part of the system to another (in technical terms across class loaders). This is most useful for classes and interfaces found in the Java Runtime like String or DataSource.
This means that in your case JNDI is just a transport mechanism and you need to have the actual connection pool defined elsewhere. Most web containers have a mechanism for defining a system wide connection pool, and JNDI then allows you to get to it.
Tomcat use a custom implementation of Apache DBCP and Apache Pool for the JNDI Datasource. These libraries are located in a single JAR at $CATALINA_HOME/lib/tomcat-dbcp.jar.
The main package is org.apache.tomcat.dbcp for avoid conflicts with the regular packages form Apache Commons.
JNDI is a mechanism of locating remote resources via lookup. It has nothing in common with connection pooling libraries. These libraries, of which c3p0, DBCP and BoneCP, are the most famous, allow you to create data sources with ability to pool connections and/or statements. If this data source is used within your application, you don't need to use JNDI, if it is located on a remote system (for instance, in Tomcat), you need to use JNDI to get access to the data source.
As a side note, why did you choose to work with old-school Servlet/JSP combo? It is a better idea to work with JSP successor, facelets that is a preferred view technology in JSF 2.x.
Another comment is to transfer management of your data source to a well-known framework. One direction might be to use an ORM, for example, Hibernate, to manage your data source (which was created with connection pooling in mind).
I have used MySqlDataSource for in jdbc connectivity.I have used following code
MysqlDataSource d = new MysqlDataSource();
d.setUser("user");
d.setPassword("pass");
d.setServerName("hostname.com");
d.setDatabaseName("db");
Connection c = d.getConnection();
Also i have searched there is an option of Configuring a MySQL Datasource in Apache Tomcat.
Is there any performance difference between these two? which one is best to use?
Configuring Datasource in tomcat will help you to share same data source between applications running in same tomcat. that Datasource will be managed by container (tomcat in your case).
while the Datasource created in code will be created by your application and can be used by that application only.
So if you have multiple application running on tomcat and accessing same data source, that configuring Datasource in tomcat will be good approach and have performance factor because only one data source is created and not having separate connections for each application
But if you have only single application that the first approach you have used is good one
They both use the internally the same driver, i dont think the performance is much different here, i guess if you need to access teh database only at that place and the enduser isn't supposed to use his own authentication you may use it directly from java, but if you will need the connectivity on different places it could be helpful to configure this using apache configuration, specially that if anything changes like database server, user name or whatever you don't need to get in the code to change it, this could be very important if end users have to set their own configurations.
The improvement of configuring a pool of Connections (as the one provided by tomcat) is mainly that you will actually create and close a lot less of connections.
When using a pool, when you request a Connection to a pool it will look if it has any connection already created and available for reuse and, if it has, it will provide you with it (instead of creating a new Connection, which is a heavy operation). You must still close() a Connection provided by Tomcat so Tomcat knows that it can now reuse when it is requested again.
Additionally, the advantage of the pool is that your code does not need to know the configuration data for the Connection. He just requests a Connection from a given pool and the sysadmin configures it, allowing for greater flexibility (the sysadmin does not need to know how to configure your app, just how to configure the Tomcat which is fairly more standard).
When creating JNDI JDBC connection pools in an application server, I always specified the type as javax.sql.ConnectionPoolDataSource. I never really gave it too much thought as it always seemed natural to prefer pooled connections over non-pooled.
However, in looking at some examples (specifically for Tomcat) I noticed that they specify javax.sql.DataSource. Further, it seems there are settings for maxIdle and maxWait giving the impression that these connections are pooled as well. Glassfish also allows these parameters regardless of the type of data source selected.
Are javax.sql.DataSource pooled in an application server (or servlet container)?
What (if any) advantages are there for choosing javax.sql.ConnectionPoolDataSource over javax.sql.DataSource (or vice versa)?
Yes, Tomcat does use Apache DBCP pooling by default for DataSources defined as JNDI Context resources.
From documentation at
http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources
NOTE - The default data source support
in Tomcat is based on the DBCP
connection pool from the Commons
project. However, it is possible to
use any other connection pool that
implements javax.sql.DataSource, by
writing your own custom resource
factory, as described below.
Digging Tomcat 6 sources revealed that they obtain connection factory this way (in case when you don't specify your own using Context's "factory" attribute):
ObjectFactory factory = (ObjectFactory)Class.forName(System.getProperty("javax.sql.DataSource.Factory", "org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory")).newInstance();
And org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory that implements javax.naming.spi.ObjectFactory takes care of creating DataSource instances:
http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/BasicDataSourceFactory.java?format=ok
I see they create instances of org.apache.tomcat.dbcp.dbcp.BasicDataSource:
http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/BasicDataSource.java?format=ok
Oddly enough, this class doesn't implement ConnectionPoolDataSource itself, neither does org.apache.tomcat.dbcp.dbcp.PoolingDataSource, that's returned internally by BasicDataSource
http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/PoolingDataSource.java?format=ok
So I presume when you configured your DataSources as javax.sql.ConnectionPoolDataSource you also used some custom-defined factory (it's just a guess, but I suppose otherwise you'd have class cast exceptions in Tomcat, since their pooling doesn't really provide instances of javax.sql.ConnectionPoolDataSource, only javax.sql.DataSource).
Thus, to answer questions about advantages or disadvantages of particular case you should compare Apache DBCP against pooling mechanism in your DataSource factory, whichever one you used.
My understanding is that only purpose of ConnectionPoolDataSource is to give access to PooledConnection which implements native pooling by JDBC driver. In this case application server can implement connections pooling using this native interface.
When using simple DataSource, appserver uses its own pooling instead of native.
Can't say which approach is best.
As for the Java docs it contains this:
DataSource Java 7 API
The DataSource interface is implemented by a driver vendor. There are three types of implementations:
Basic implementation -- produces a standard Connection object
Connection pooling implementation -- produces a Connection object that will automatically participate in connection pooling. This implementation works with a middle-tier connection pooling manager.
Distributed transaction implementation -- produces a Connection object that may be used for distributed transactions and almost always participates in connection pooling. This implementation works with a middle-tier transaction manager and almost always with a connection pooling manager.
PooledConnection Java 7 API
An application programmer does not use the PooledConnection interface directly; rather, it is used by a middle tier infrastructure that manages the pooling of connections.
When an application calls the method DataSource.getConnection, it gets back a Connection object. If connection pooling is being done, that Connection object is actually a handle to a PooledConnection object, which is a physical connection.
The connection pool manager, typically the application server, maintains a pool of PooledConnection objects ....
So in the end you just use DataSource and Connection classes and never PooledConnection / ConnectionPoolDataSource, if you are a happy and normal programmer.
If are implementing an Application Server that's another story...