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.
Related
I have a scenario where I need to configure the Mongo DB in Java Application. I don't use Spring, but I need to make the connection to DB as common so that whenever there is a transaction that is going to happen, it must create a connection automatically and it must close the connection when the transaction is done.
EDIT:
How to make the connection common instead of creating the instance each time when the transactions are done?
You can see an example of transactions working with Java code (and without Spring):
Article: https://www.mongodb.com/blog/post/java-and-mongodb-40-support-for-multidocument-acid-transactions
GitHub: https://github.com/MaBeuLux88/mongodb-4.0-demos
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.
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).
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...
Is it possible to use bitronix.tm.resource.jdbc.PoolingDataSource without using bitronix transaction manager and using standalone JBossTS instead?
For database access I use Hibernate, with transaction demarcation done with Spring's #Transactional annotation (or Spring's TransactionTemplate which has similar implementation). PoolingDataSource and standalone JBossTS is used in tests, however I'd like not to abandon db connection pooling.
If it's not possible, what other pooling data source will fit here? Some other question suggests c3p0 is not an option. Is it true?
No, that's not possible and it's also not possible to switch XA pools between transaction managers simply because there is no standard defining the communication between the transaction manager and the JDBC connection pool. At least that's the short story, the long one is here: http://blog.bitronix.be/2011/02/why-we-need-jta-2-0/
AFAIK in the JBossTS case your only options are to use the JBossAS connection pool but that would not be a minor achievement as it requires at least a JCA runtime, but certainly more.
I'm afraid the only realistic options are to use all of BTM or JBossTS without connection pooling or JBossTS with pooling but inside JBossAS.