Develop Reference

Can we use Atomikos Transaction Manager with Tomcat JDBC XA Connection Pool

I need to use Atomikos transaction Manager with Tomcat 8.0.36 to support JTA. Every documentation for Atomikos, recommend using com.atomikos.jdbc.AtomikosDataSourceBean as the type and com.atomikos.tomcat.EnhancedTomcatAtomikosBeanFactory as the object factory for the datasource resource (specified as resource in tomcat's context.xml)
However, if we use com.atomikos.jdbc.AtomikosDataSourceBean, Atomikos will use its own JDBC connection Pool instead of Tomcat's connection Pool.
Tomcat's connection pool provides more configurable settings than atomikos.
Is it possible to use Datasource resource, with type as javax.sql.XADatasource and factory as org.apace.tomcat.jdbc.pool.DatasourceFactory (which will use Tomcat's XA connection Pool) with Atomikos?

I tried to use atomikos with tomcat JDBC pool i.e. I didn't use AtomikosDatasourceBean (which is the only recommended way in Atomikos documentation). So far I have tested this with 3-4 applications and it seems to work fine.
Atomikos documentation doesn't provide much detail about it, however, there is one sentence on its website which says that we can use other JDBC pool with tomcat.

Adavantage of using connection from Data Source over JDBC Driver Manager

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.

How to apply connection pooling?

I am specific about this tutorial: The BalusC Code: DAO tutorial - use in JSP/Servlet
How can I apply connection pooling together with this code? What will be the changes in the code?

I'm not sure about Tomcat, but at least Application Servers such as GlassFish come with connection pool functionality integrated. You just need to configure the connection details in the admin interface. Then in your EJB use:
#PersistenceContext
private EntityManager em;
The container will take care of the connection pooling.

Using spring to connect to mysql, how to mimick connection pool?

I'm using spring to connect to mysql currently.
I'm thinking of moving to simply servlets and drop spring as I don't need 99% of spring's functionality.
What do you suggest I use to get connection pooling functionality? Is there a mysql connection pool that is framework independent?

Even if you don't need 99% of Spring's features you can still use Spring JDBC which by itself is worthwhile. You don't need the whole Spring infrastructure to use it either - you can drop it in and use it by itself...no DI required. I have a coworker who is using Stripes as his app's framework but uses Spring JDBC for database access.
You don't say what your container is (e.g. Tomcat, JBoss, etc) but there are several container independent connection pools to choose from, such as DBCP, c3p0, BoneCP. If you're using Tomcat 7 it ships with a new connection pool called The Tomcat JDBC Connection Pool (I guess their marketing budget was cut :) ).
We just switched from DBCP to Tomcat's connection pool and it works great. We haven't run any benchmarks on it but haven't run into any issues yet either.
I recommend sticking with Spring JDBC even if you use another connection pool, just for the database connection/statement management, disconnected result set, and "free" prepared statements (Spring JDBC creates prepared statements under the hood for you).

DataSource or ConnectionPoolDataSource for Application Server JDBC resources

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...