Simple implementation of the standard JDBC DataSource interface, configuring
a plain old JDBC Driver via bean properties, and returning a new Connection
for every getConnection call.
NOTE: This class is not an actual connection pool; it does not actually
pool Connections. It just serves as simple replacement for a full-blown
connection pool, implementing the same standard interface, but creating new
Connections on every call.
Useful for test or standalone environments outside of a J2EE container, either
as a DataSource bean in a respective ApplicationContext, or in conjunction with a
simple JNDI environment. Pool-assuming Connection.close() calls will
simply close the Connection, so any DataSource-aware persistence code should work.
In a J2EE container, it is recommended to use a JNDI DataSource provided by
the container. Such a DataSource can be exposed as a DataSource bean in a Spring
ApplicationContext via JndiObjectFactoryBean, for seamless switching to and from
a local DataSource bean like this class. For tests, you can then either set up a
mock JNDI environment through Spring's SimpleNamingContextBuilder, or switch the
bean definition to a local DataSource (which is simpler and thus recommended).
If you need a "real" connection pool outside of a J2EE container, consider
Apache's Jakarta Commons DBCP
or C3P0.
Commons DBCP's BasicDataSource and C3P0's ComboPooledDataSource are full
connection pool beans, supporting the same basic properties as this class
plus specific settings (such as minimal/maximal pool size etc).
Commons DBCP's BasicDataSource can even be used as a direct replacement for an
instance of this class just by changing the class name of the bean definition to
"org.apache.commons.dbcp.BasicDataSource", because the names of all common
properties match exactly. Note that both BasicDataSource and ComboPooledDataSource
should be defined with destroy-method="close", for immediate shutdown when the
Spring ApplicationContext shuts down.
getConnectioncall.NOTE: This class is not an actual connection pool; it does not actually pool Connections. It just serves as simple replacement for a full-blown connection pool, implementing the same standard interface, but creating new Connections on every call.
Useful for test or standalone environments outside of a J2EE container, either as a DataSource bean in a respective ApplicationContext, or in conjunction with a simple JNDI environment. Pool-assuming
Connection.close()calls will simply close the Connection, so any DataSource-aware persistence code should work.In a J2EE container, it is recommended to use a JNDI DataSource provided by the container. Such a DataSource can be exposed as a DataSource bean in a Spring ApplicationContext via JndiObjectFactoryBean, for seamless switching to and from a local DataSource bean like this class. For tests, you can then either set up a mock JNDI environment through Spring's SimpleNamingContextBuilder, or switch the bean definition to a local DataSource (which is simpler and thus recommended).
If you need a "real" connection pool outside of a J2EE container, consider Apache's Jakarta Commons DBCP or C3P0. Commons DBCP's BasicDataSource and C3P0's ComboPooledDataSource are full connection pool beans, supporting the same basic properties as this class plus specific settings (such as minimal/maximal pool size etc).
Commons DBCP's BasicDataSource can even be used as a direct replacement for an instance of this class just by changing the class name of the bean definition to "org.apache.commons.dbcp.BasicDataSource", because the names of all common properties match exactly. Note that both BasicDataSource and ComboPooledDataSource should be defined with destroy-method="close", for immediate shutdown when the Spring ApplicationContext shuts down.