DB connection pool in Standalone Axis2? - java

For my services in production environment I always set up DB connections pool in Tomcat's context.xml:
<Resource name="jdbc/MyDB" auth="Container" type="javax.sql.DataSource"
maxActive="256" maxIdle="5" maxWait="10000"
removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true"
username="xxx" password="xxx" driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://host:3306/dbname?autoReconnect=true"
validationQuery="SELECT 1"
/>
Then later in my service I use:
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/MyDB");
Connection db = ds.getConnection();
For development I want to run Axis2 standalone - is there a way how I could set up somewhere DB connections pool in Axis as well so I would not need to modify service code and use it the same way as with Tomcat?

Why not have different context.xml files for different environments.
e.g.
context_DEV.xml
context_UAT.xml
context_PROD.xml
and then use a symlink to point to the correct one.
e.g.
context.xml -> context_DEV.xml
Also, see this thread which recommends using a servlet container (such as Tomcat) rather than axis2 standalone server for stability.

Related

Tomcat7 MySQL connector inconsistency

This is a bit of a weird one question and I cannot for the life of figure out what's going on. I have two applications (WARS) running on a Tomcat7 instance. Both of them connect to a database and get that connection using JNDI. The datasource reference specified in the tomcat context.xml file as follows.
Tomcat7/conf/context.xml
<Resource name="jdbc/dataSourceOne" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000" username="user" password="pass" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost/databaseone" />
<Resource name="jdbc/dataSourceTwo" auth="Container" type="javax.sql.DataSource" maxActive="100" maxIdle="30" maxWait="10000" username="user" password="pass" driverClassName="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost/databasetwo" />
WEB-INF/lib
Both applications have a copy of the mysql connector jar in their lib folders.
mysql-connector-java-5.1.34.jar
Now here's where it gets weird, application 1 works straight out of the box. I just need to deploy the WAR on my tomcat instance and it's all systems go. It gets its datasource and can connect to it's database with absolutely no problems.
However, when I try and deploy application 2, I get a MySQL class not found exception. Now the fix for this is to add the above mysql connector jar to the tomcat7/lib folder.
My question is why do I need only need to add this for my second application? If tomcat7 requires the mysql connector jar why does my first application work without any modification to the tomcat7 setup at all?
It just doesn't make sense that one application will work but the other won't without the modification.
Any help would be greatly appreciated folks.
#Gimby - Turns out you were right, application 1 wasn't actually using the datasource defined in tomcats context.xml file. Thanks for the input, really appreciate the help.

Tomcat Connection Pool under WEB-INF/context.xml or TOMCAT_HOME/conf/server.xml?

This is the first time I'm trying to set up a connection pool in tomcat (version 8), and I'm kind of confused. It seems that I have 2 options available to me, 1) I can add something similar to this:
<?xml version="1.0" encoding="UTF-8"?>
<Context>
<!-- Specify a JDBC datasource for oracle -->
<Resource name="jdbc/testdb"
auth="Container"
type="javax.sql.DataSource"
username="DB_USERNAME"
password="DB_PASSWORD"
driverClassName="oracle.jdbc.driver.OracleDriver"
url="jdbc:oracle:thin:#xxx:1525:dbname"
maxActive="10"
maxIdle="4" />
</Context>
In a file called 'context.xml' in my projects WEB-INF folder. OR, 2) I can add something like this:
<Context path="/dbcp" docBase="dbcp" debug="5"
reloadable="true" crossContext="true">
<Resource name="jdbc/TestDB" auth="Container"
type="javax.sql.DataSource" removeAbandoned="true"
removeAbandonedTimeout="30" maxActive="100"
maxIdle="30" maxWait="10000" username="kunal"
password="java_facier"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost/dbcptest"/>
</Context>
in TOMCAT_HOME/conf/sever.xml and then add this:
<resource-ref>
<description> DB Connection Pooling</description>
<res-ref-name> jdbc/TestDB</res-ref-name>
<res-type> javax.sql.DataSource</res-type>
<res-auth> Container</res-auth>
</resource-ref>
to my WEB-INF/web.xml file in my project...
If I'm correct in both instances here, which one is better to use? Also where would I put my database vendors jdbc-driver?
Put JDBC libraries to $tomcat/lib folder so that webapp reloads don't touch it. I have found this the best common rule and even an official Apache Tomcat documentation instructs $CATALINA_HOME/lib folder so please follow their wisdom.
$tomcat/webapps/mywebapp/META-INF/context.xml
This provides you an application level pool. You having two or more webapps connecting to a same database each have own pool. It means they obye own private max-limit and such meters. Distributing and installing mywebapp.war file is easy, this is a self-contained application.
$tomcat/conf/server.xml
This provides a global pool where two or more webapps share same max-limit and such meters. If you must control the overall number of connections opened to the db engine this is where you should put jdbc settings. Tomcat admin must put this setting in place before deploying a webapp.
edit: Oh I see you have put jdbc settings inside the <Context> element in server.xml file. Well, in that case I think its still a webapp-private pool. If you need global pool you add it inside <GlobalNamingResources> element at the top of xml file.
Either approach has it pros and cons :
1. Application level packaging creates App local connection pools.
2. Independent from Tomcat's setup
but,
Application on release requires environment specific releases.
While, if tomcat maintains connection pool then app only depends on "Registered Name" and single package can be distributed for all environments.
Just to summarize, App level packaging is developer centric whereas Tomcat-maintained connection pools are Operational friendly.

Mimic Tomcat's JNDI datasource for Crystal Reports Java API in stand-alone program

Apparently this Tomcat data source gets registered in JNDI. The crystal reports API will then find the "jdbc/TESTDB" (below) under the JNDI name of "TESTDB". What is the easiest way to set this up in a stand-alone program? I have several data-sources reports, so my preferred method is to configure all JNDI entries so any that are needed will be referenced and used on-demand. Existing reports will not change and reference the ODBC connections.
I need to mimic this JNDI Tomcat entry in a stand-alone application. I'm not concerned about any of the max parameters:
<Context>
<Resource name="jdbc/TESTDB" auth="Container" type="javax.sql.DataSource"
maxActive="100" maxIdle="30" maxWait="10000"
username="user" password="passwd" driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:#dbserver:1521:db1"/>
</Context>
This is the crystal reports example that shows this setup in action using Tomcat:
http://www.javathinking.com/2011/09/using-the-crystal-reports-java-api-to-generate-pdf/
You need a JNDI provider. SimpleJNDI - http://code.google.com/p/osjava/wiki/SimpleJNDI - is usable in a application scenario outside a Java EE container.
You will need to investigate how to represent the data structure that Crystal Report needs, in the formats supported by SimpleJNDI.

How to configure a global JNDI datasource in Tomcat 6?

I'm struggling to configure a simple JNDI pooled datasource in Tomcat 6.0.32.
I want to create the datasource definition outside my web application artifact. Basically I don't want my application to know the credentials to access the database server.
I was under the assumption that, like in Weblogic, it should be possible to create a "global" JNDI datasource in Tomcat, but so far I have been unsuccessful.
I have tried to add the datasource definition in CATALINA_HOME/conf/context:
<Resource name="jdbc/mydb"
auth="Container"
type="javax.sql.DataSource" driverClassName="oracle.jdbc.OracleDriver"
factory="oracle.jdbc.pool.OracleDataSourceFactory"
url="jdbc:oracle:thin:#1.1.1.1.:xxx"
user="xxxx"
password="yyyy"/>
The result is that the server outputs the following line, when booting:
SEVERE: Null component Catalina:type=DataSource,path=/,host=localhost,class=javax.sql.DataSource,name="jdbc/mydb"
Any pointer would be appreciated.
Move your data source configuration to server.xml <GlobalNamingResources>. (And don't forget to add the driver jar file to tomcat lib).
Configure your context.xml so that all Application are aware of the global resource.
<Context>
<WatchedResource>WEB-INF/web.xml</WatchedResource>
<ResourceLink global="jdbc/mydb" name="jdbc/mydb" type="javax.sql.DataSource"/>
</Context>
Your mistake: user="xxxx", you need to write username="xxxx" instead.

How to shrink DB Connection Pool?

I am using Apache DBCP with JNDI in my tomcat container to pool connections to a mysql database. Everything works fine but a problem i am seeing is that once a pconnection is pooled it is never released. So after a load spike connection sit their forever sleeping. Is their a way to shrink the pool through context.xml parameters? here is my ocnfiguration:
defaultAutoCommit="false"
defaultTransactionIsolation="REPEATABLE_READ"
auth="Container"
type="javax.sql.DataSource"
logAbandoned="true"
removeAbandoned="true"
removeAbandonedTimeout="300"
maxActive="-1"
initialSize="15"
maxIdle="10"
maxWait="10000"
username="user"
password="password"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost/mydb"/>
Try to set minEvictableIdleTimeMillis to lower value than its default, which is 1000*60*30.
try to use c3p0 connection pool`~~
In comparable situations I've used Tomcat's JMX adapter to tweak the settings of the connection pool. This can be used both, to increase and to decrease thesize of the pool. It is therefore a good idea to enable JMX remote access to the servlet container at least in production environments, just to have some chance to react on exceptional operational situations.

Categories