By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,018 Members | 930 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,018 IT Pros & Developers. It's quick & easy.

DB2 connection Pooling

P: n/a
Does COM.ibm.db2.jdbc.DB2DataSource, (which supports connection
pooling) need to be run within a J2EE container environment before the
connection pooling facility is actually available to a user?

Thanks John
Nov 12 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
COM.ibm.db2.jdbc.DB2DataSource is an implementation of the Type 2
connection driver. This driver goes through the (UDB) client code
installed on the system where the application is running.

As far as I know, any connection pooler that sits between applications
and the CLI code should work.

Connection pooling is usually not considered to be "available to the
user". It's an interfacing layer for performance that lies outside the
application; which should have no access to it. The presence or absence
of connection pooling shouldn't make any difference to the application code.
Phil Sherman

John wrote:
Does COM.ibm.db2.jdbc.DB2DataSource, (which supports connection
pooling) need to be run within a J2EE container environment before the
connection pooling facility is actually available to a user?

Thanks John


Nov 12 '05 #2

P: n/a
aka
Hi John,

perhaps you want to try something like this:

COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource ds = new
COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource();
ds.setDatabaseName(...);
ds.setUser(...);
ds.setPassword(...);

javax.sql.PooledConnection c = null;
c = ds.getPooledConnection(...)

I dont't know which connection type this is, but I would think this is type
2...

Regards aka.
"John" wrote in message
news:e5**************************@posting.google.c om...
Does COM.ibm.db2.jdbc.DB2DataSource, (which supports connection
pooling) need to be run within a J2EE container environment before the
connection pooling facility is actually available to a user?

Thanks John

Nov 12 '05 #3

P: n/a
Phil,

The problem - I have 'working' JDBC code that makes use of data source
and pooling, called as follows (its happens to be as aka's post
described.) I use DB2 UDB 7 fix (pack 12). The problem is it takes
600msec to get a connection - I suspect pooling is not 'turned on'.
The crux is I'm running outside of a container - What am I doing
wrong? DB2Java.zip facilitates a developer creating your own pooling -
but I dont want to do that!

dsource = new COM.ibm.db2.jdbc.DB2DataSource();
Context ctx = null;
Hashtable env = new Hashtable(5);
env.put ("java.naming.factory.initial",
"COM.ibm.db2.jndi.DB2InitialContextFactory");
ctx = new InitialContext(env);
ctx.bind(dataSourceName, dsource);
ds = (DataSource) ctx.lookup(dataSourceName);
conn = ds.getConnection(datasourceUser, datasourcePassword);
Nov 12 '05 #4

P: n/a
aka

"John" wrote in message
news:e5**************************@posting.google.c om...
Phil,

The problem - I have 'working' JDBC code that makes use of data source
and pooling, called as follows (its happens to be as aka's post
described.) I use DB2 UDB 7 fix (pack 12). The problem is it takes
600msec to get a connection - I suspect pooling is not 'turned on'.
The crux is I'm running outside of a container - What am I doing
wrong? DB2Java.zip facilitates a developer creating your own pooling -
but I dont want to do that!

dsource = new COM.ibm.db2.jdbc.DB2DataSource();
Context ctx = null;
Hashtable env = new Hashtable(5);
env.put ("java.naming.factory.initial",
"COM.ibm.db2.jndi.DB2InitialContextFactory");
ctx = new InitialContext(env);
ctx.bind(dataSourceName, dsource);
ds = (DataSource) ctx.lookup(dataSourceName);
conn = ds.getConnection(datasourceUser, datasourcePassword);


if you say that the last line of your code takes 600ms on subsequent calls,
then this could be some problem (depending on your environment, machine,
network and so on), if you mean all of the above lines take 600ms that
should be a reasonable time, in particular if it is for your first
connection. one other thing that could speed things up is to set the userid
and password on the data source rather then doing authentication every time
when getting a connection from the pool (or context), if this is applicable
in your case. if you mean application server when speeking of j2ee
container, then the app server will most likely do the connection pooling
stuff, if you run your code outside then you have to do the work by
yourself...in the above example you create a new connection capable of
pooling every time you run it.
by only getting the connection i achieve typically about 31ms or even 0ms
(due to the bad granularity of timer updates about 1/17sec) on my Wintel box
with local db, but the first connection takes notably longer, espacially if
it is the first connection to the db at all.

maybe i didn't get your problem?

Regards aka.
Nov 12 '05 #5

P: n/a
Thanks for the response(s),

Its the last line that takes ages & I am running it outside of a J2EE
container. I get the impression that you believe it needs to run
within a container to get the benefit of pooling?

My problem is compounded in that I have to port it to Oracle. Since I
made use of DB2Java.zip '.jndi.DB2InitialContextFactory' and an
equivelent is not available withon Oracles classes12.zip. I will have
to resort to using JDBC and forget DataSources. Since I only need a
single connection per process - I'l hold it open passing it forward
for the next client user.

Thanks John
Nov 12 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.