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...
Related
is it possible to intercept the connection pooling mechanism of a DataSource in a JEE container?
For (un)setting some information on the connection's context I'm searching for a way to intercept the pooling mechanism so that I know when and which connection is put back into the pool.
So does anyone know a (common) way to do this?
Some additional info:
The application runs on Wildfly
Using Hibernate for ORM
The option connection-listener in datasource configuration can be the solution.
connection-listener:
An org.jboss.jca.adapters.jdbc.spi.listener.ConnectionListener that
provides a possible to listen for connection activation and
passivation in order to perform actions before the connection is
returned to the application or returned to the pool
You can create a custom implementation of org.jboss.jca.adapters.jdbc.spi.listener.ConnectionListener and deploy it as a module to do that you want.
I am using org.apache.commons.dbcp.BasicDataSource in my hibernate for connection pooling. and i also used the below method :
basicDataSource.setAccessToUnderlyingConnectionAllowed(true);
Now i want to use the c3p0 connection pooling. and i am trying to use above method but it is not available in ComboPooledDataSource class. so anyone can help me to give me the alternative of this method.
If you need to access the underlying Connection in c3p0:
use raw Connection operations, see http://www.mchange.com/projects/c3p0/#raw_connection_ops
if you are using JDBC4 and a c3p0-0.9.5-pre release (-pre8 is production quality I think, just a few loose ends left to clean up), then you can use the standard JDBC4 unwrap method.
You don't need to set that kind of method for C3P0. Hibernate allows you to use:
an internally wired C3P0
or an external supplied C3P0 DataSource
Either way, all connections are going to be monitored by the C3P0 internal guards and Hibernate works seamlessly with any of those two alternatives.
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 am using the PostgreSQL 9.1 JDBC4 driver (postgresql-9.1-902.jdbc4.jar) in a Java EE application deployed in JBoss 7.
Can I assume that javax.sql.DataSource is thread-safe so that multiple threads can concurrently call the getConnection() method on it?
javax.sql.DataSource itself is an interface, so it is a specific to the implentation if it is thread-safe or not.
For the PostgresSQL driver, the official documentation changed over time. While older documentation (snapshot) wrote it is, the current documentation writing the opposite, stating that is not thread-safe.
Typically the DataSource implementation you get from a Java EE container will be a thread-safe object backed by a connection pool, and thread-safety (or otherwise) of the underlying JDBC connections is not really relevant. The usual pattern when you need to talk to the database is to call getConnection() on the data source to obtain a connection object, make the necessary database calls and then close() the connection. Under the covers this won't actually close the underlying connection, but simply return it to the connection pool for future use. Any individual connection will only be used by one thread at a time.
This is the idiom used by things like the Spring JdbcTemplate.
If it's a 'Connection pooling implementation', then it should be thread safe.
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.