What's the difference between MysqlConnectionPoolDataSource and C3p0, BoneCP or dbcp library for connection pooling? I don't understand why use a library if mysql connector give connection pooling.
A ConnectionPoolDataSource is not a connection pool (or at least: it shouldn't be), it is intended to be used by a DataSource that provides pooling (eg from an application server). A ConnectionPoolDataSource provides the physical connections that will be held in the connection pool. Besides creating those physical connections a ConnectionPoolDataSource shouldn't do anything else.
So if you are working in an application server, use the pooling provided by the DataSources of the application server. If you are in a standalone application or a server that doesn't provide datasources on its own, use third party connection pools like BoneCP, c3p0 or Apache DBCP. If MySQL also provides a normal DataSource that provides pooling, then you could use that.
Related
Reading the neo4j JDBC's documentation, there are two transports supported for connecting to a neo4j server at the moment:
through the Bolt protocol (3.0.X) using jdbc:neo4j:bolt://:/
through the HTTP protocol (2.X+) using jdbc:neo4j:http://:/
Obviously, the HTTP protocol does not need pooling connections (unless it's HTTP/2 which is not the case here). But I'm not familiar with Bolt so I'm wondering if I can pool neo4j's connections in Bolt mode? And if I can, is it like any ordinary JDBC connection and I can use, for example, HikariCP to keep its connections alive?
Neo4j driver handles for you a pool of connection to the database.
Take a look here if you want to see the default config : https://github.com/neo4j/neo4j-java-driver/blob/1.1/driver/src/main/java/org/neo4j/driver/internal/net/pooling/PoolSettings.java
For now, you can't configure the bolt java driver via the JDBC one, you can only specify the EncryptionLevel. (https://github.com/neo4j-contrib/neo4j-jdbc/blob/master/neo4j-jdbc-bolt/src/main/java/org/neo4j/jdbc/bolt/BoltDriver.java#L58-L60)
Cheers
I'd like to add XA connection pool to my Spring based application, specifically Oracle UCP. This pool works on XADataSource and XAConnection objects. Standard DataSource.getConnection(...) methods are not supported.
Trying working with that pool (that I am able to successfully set up in Spring) I am getting an error related to the fact that getConnection(...) methods invoked by JdbcTemplate are disabled and should not be used. I am just wondering whether any of Spring JDBC classes are able to work with XADataSource and XAConnections? Probably there are another ways to use Spring with XA connection pools? Will appreciate any advices on that topic.
Just for those who may experience similar problems - Spring doesn't support directly XA connection pools (through native XADataSource.getXAConnection(...) methods). You need to write a kind of wrapper utilizing DatSource.getConnection(...) methods.
Official Sybase jConnect Programmers Reference suggests following way to use pooled connections:
SybConnectionPoolDataSource connectionPoolDataSource = new SybConnectionPoolDataSource();
...
Connection ds = connectionPoolDataSource.getConnection();
...
ds.close();
However getDataSource always causes exception. I decompiled SybConnectionPoolDataSource and found that the method call explicitly generates an error:
public Connection getConnection() throws SQLException
{
ErrorMessage.raiseError("JZ0S3", "getConnection()");
return null;
}
Does anyone have an idea why the documentation contradicts to the implementation?
I can't comment specifically for Sybase because 1) I don't use it and 2) your link doesn't work, but I can try to give you a theory based on my own experience maintaining a JDBC driver (Jaybird/Firebird JDBC) and looking at what some of the other implementations do.
The ConnectionPoolDataSource is probably the least understood part of the JDBC API. Contrary to what the naming suggests and how it has been implemented in some JDBC implementations this interface SHOULD NOT provide connection pooling and should not implement DataSource (or at least: doing that can lead to confusion and bugs; my own experience).
The javadoc of the ConnectionPoolDataSource is not very helpful, the javax.sql package documentation provides a little bit more info, but you really need to look at the JDBC 4.1 specification, Chapter 11 Connection Pooling to get a good idea how it should work:
[...] the JDBC driver provides an implementation of ConnectionPoolDataSource that the application server uses to build and manage the connection pool.
In other words: ConnectionPoolDataSource isn't meant for direct use by a developer, but instead is used by an application server for its connection pool; it isn't a connection pool itself.
The application server provides its clients with an implementation of the DataSource interface that makes connection pooling transparent to the client.
So the connection pool is made available to the user by means of a normal DataSource implementation. The user uses this as would it be one that doesn't provide pooling, and uses the connections obtained as if it is a normal physical connection instead of one obtained from a connection pool:
When an application is finished using a connection, it closes the logical connection using the method Connection.close. This closes the logical connection but does not close the physical connection. Instead, the physical connection is returned to the pool so that it can be reused.
Connection pooling is completely transparent to the client: A client obtains a pooled connection and uses it just the same way it obtains and uses a non pooled connection.
This is further supported by the documentation of PooledConnection (the object created by a ConnectionPoolDataSource):
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. If there is a PooledConnection object available in the pool, the connection pool manager returns a Connection object that is a handle to that physical connection. If no PooledConnection object is available, the connection pool manager calls the ConnectionPoolDataSource method getPoolConnection to create a new physical connection. The JDBC driver implementing ConnectionPoolDataSource creates a new PooledConnection object and returns a handle to it.
Unfortunately, some of JDBC drivers have created data sources that provide connection pooling by implementing both DataSource and ConnectionPoolDataSource in a single class, instead of the intent of the JDBC spec of having a DataSource that uses a ConnectionPoolDataSource. This has resulted in implementations that would work if used as a normal DataSource, but would break if used as a ConnectionPoolDataSource (eg in the connection pool of an application server), or where the interface was misunderstood and the wrong methods where used to create connections (eg calling getPooledConnection().getConnection()).
I have seen implementations (including in Jaybird) where the getPooledConnection() would be used to access a connection pool internal to the implementation, or where only connections obtained from the getConnection() of the implementation would work correctly, leading to all kinds of oddities and incorrect behavior when that implementation was used to fill a connection pool in an application server using the getPooledConnection().
Maybe Sybase did something similar, and then decided that wasn't such a good idea so they changed the DataSource.getConnection() to throw an exception to make sure it wasn't used in this way, but at the same time maintaining the API compatibility by not removing the methods defined by DataSource. Or maybe they extended a normal DataSource to easily create the physical connection (instead of wrapping a normal one), but don't want users to use it as a DataSource.
My application is using Websphere 6.1, Spring JDBC and oracle.I am using connection pooling to manage the connections.Is there any way to find out the number of connections active(alive) between the application and database at any point of time?.Can we have any indicator to let us know when a connection is/was dropped?
One option would be to manage your connection pool via JMX. Spring has excellent support for it. You just need to expose your connection pool bean via org.springframework.jmx.export.MBeanExporter. You can pick and choose the methods you want to expose. For example if you use DBCP you can use the method BasicDataSource#getNumActive().
We are working on an IBM WebSphere MQ application, and we use JMS API to operate the message. But we have a problem that the connection takes too much time, and we want to pool the JMS connection, for it's a standalone application, we have no application container to provide JNDI or pooling service. So is there a solution to resolve this? For JDBC we can use DBCP or c3p0 to archive pooling datasource, in JMS, is there any similar project that can pool JMS connections?
It used to be that the JMS MQConnectionFactory had pooling built in, but it seems that in version 7, it has been removed.
Set the use of ConnectionPooling in earlier versions of the WebSphere
MQ classes for JMS. This method is retained for compatibility with
older MQJMS applications, but, because this Connection Pooling
functionality has been removed from version 7, setting this property
will have no effect.
In the absence of anything else, you can use Apache Commons Pool. Same idea as DBCP (which uses Pool) but for non JDBC objects.
Spring's CachingConnectionFactory works well for this use case.
This answer in https://stackoverflow.com/a/31119435/1765341 explains how to do this in Tomcat, but the code there can easily be adapted for Java standalone applications. This should be much easier (and less error prone) than writing an Apache Commons Pool implementation.