Can anyone share the origin and meaning of the jdbc connection pool named c3p0.
Was it inspired from star wars?.
Quoting Steve Waldman (C3P0 Developer) in the Hibernate forums:
re: why c3p0? mostly because it began as an attempt to see how hard it would be to implement connection pooling as defined by the JDBC 3.0 specification. Connection Pooling 3.0 --> cp30 --> c3p0. Also, I was working on a (never completed, and now obseleted) project for easy-to-use access to berkeley db from java, and that was called bdbd. A robot in an old television show (Buck Rogers) always said "bdbd", and c3p0 was a robot too. The pairing of names was a private little joke.
Related
The JDBC documentation from Oracle says that driver provider should implement DataSource interface, but in real project source file, I always see the DataSource come from 3rd, such as DBCP connection pool.
I wonder if MySQL driver in itself implements DataSource interface?
If you are talking about Connector/J, it provides:
com.mysql.jdbc.jdbc2.optional.MysqlDataSource (which implements DataSource),
com.mysql.jdbc.jdbc2.optional.MysqlConnectionPoolDataSource (which implements ConnectionPoolDataSource)
com.mysql.jdbc.jdbc2.optional.MysqlXADataSource (which implements XADataSource)
So, as far as your question goes. Yes Connector/J provides implementations to the DataSource interface and conforms with JDBC specs.
But, as you are aware by your question and #Piotr's answer, most applications will never deal with those implementations directly. At least in ten years as a Java Developer I have never done that. Let the Java EE App Server handle connections for you, or install a third party connection pool if you are down to standalone applications.
You can use native DataSource provided by JDBC driver, but what you usually do is you use a connection pool like DBCP, C3P0 or BoneCP.
I was connecting to DB2 systems using org.apache.commons.dbcp.BasicDataSource and I have
found that com.ibm.db2.jcc.DB2DataSource is more extensive as it allows me to generate traces.
Now I would like to know the difference more accurately and which is preferable as I believe that BasicDataSource is light as compared to DB2DataSource.
org.apache.commons.dbcp.BasicDataSource is actually a connection pool, from which you can borrow/return connections to any flavour of database: Oracle, Sybase, DB2, etc.
com.ibm.db2.jcc.DB2DataSource is a DB2 data source.
So, you could have a DBCP pool of perhaps 100 DB2 connections. The pool will return you a pretty generic datasource for use in your code - unless you cast it explicitly to a DB2 one e.g. in order to get access to its fuller API. Edit following comment below: you shouldn't really need to do this, normal idiom of use is to go with the regular DataSource interface.
Read more about DBCP and its configuration options at:
http://commons.apache.org/proper/commons-dbcp/index.html
http://commons.apache.org/proper/commons-dbcp/configuration.html
I am reading about Connections vs DataSources in Java and I have some questions. Is a DataSource really just a manager and an abstraction of a Connection (or multiple connections)?
From docs:
A factory for connections to the physical data source that this DataSource object represents. An alternative to the DriverManager facility, a DataSource object is the preferred means of getting a connection.
Actually, a DataSource is a provider of Connections and it has a variety of implementations which operate in different manners. Such as:
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.
Connection is the connection :) DataSource is a manager of connections (pool of connections).
Data source is the source of your data, the connection is the driver.
DataSource is ill concept in its existing form as if it was meant to abstract interactions it should not return some SQL connection to interact with in the first place. Also it is overkill and XA is fantasy concept that some paid dearly for lack of reliable implementation in the world (I mean all enterprise commercial implementers simply fail and expose business... someone got hurt because of it in finance, but I will not mention names). In general, regardless if Sun or Oracle recommends it, it results in over-engineering and some technical dirt in code (dealing with contexts, extra steps to get to data, some external configurations... and in the end it is still specific to vendor implementations anyway). Some developed coroporate solutions that deal with pooling, connection recovery e.t.c much better based on plain connections and DriverManager than DataSource implemtations provided by enterprise DBMS vendors.
For the record I worked with both and I base it on facts encountered in different places. And if you doubt it then ask why you can see plain JDBC URL in Hibernate configuration all over the place in businesses. Many simply dump the heavyweigtt idea of J2EE and go lightweight... also using plain connections based on DriverManager.
You want to get your career on line then go ahead with XA DataSources and recovery of failed transactions where poor XA implemetation failed badly.
I am creating a JDBC connection pool resource for GlassFish, using the server's Admin Console.
One of the fields on the page to create the pool is labeled 'Resource Type'. This field has four possible values: javax.sql.DataSource, javax.sql.XADataSource, javax.sql.ConnectionPoolDataSource and javax.sql.Driver, but the help text for the Create JDBC connection pool 'wizard' does not have much info about the advantages and disadvantages of these choices.
When prompted to pick a resource type which should I choose?
I am going to connect to a local MySQL server. It would be nice to get an explanation of the differences between the choices in the drop-down as well.
Below are the scenarios where you would need each of the resource types listed. Hope this helps.
DataSource
DataSource A DataSource object is a factory for Connection objects. When using simple DataSource, appserver uses its own pooling instead of native.
ConnectionPoolDataSource
A ConnectionPoolDataSource object is a factory for PooledConnection objects. ConnectionPoolDataSource is used 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. Please refer to Java API to know what a PooledConnection is...A ConnectionPoolDataSource can use a third party implementation for pooling - as far as I know for Tomcat, for instance, DBCP connection pooling is used.
XADataSource
You need an XADataSource if you want to execute a Distributed Transaction. You should use XADataSource instead of DataSource if the application
Uses the Java Transaction API (JTA)
Includes multiple database updates within a single transaction
Accesses multiple resources, such as a database and the Java Messaging Service (JMS), during a transaction
I've been looking at a number of JDBC connection pools, but I have the specific requirement that the pool needs to be JTA aware, which leaves me with a short list of Apache DBCP and OW2 XAPool. The other pools I looked (c3p0, Proxool, BoneCP) at did not appear to satisfy the JTA requirement.
Does anyone have a recommendation about either XAPool, DBCP, or a connection pool I have not mentioned here?
Some standalone transaction managers like Atomikos or Bitronix have their own integrated connection pool. Such a pool is JTA compliant and would solve your problem.
Recently I was facing the same problem and finally I ended up with Bitronix and its integrated connection pool. It works well.
If timelines permit and there's this requirement, I can add JTA support to BoneCP if you want.
Wallace
(BoneCP author)