Most efficient way to get a connection from a defined connection -pool [whole message]

Question

Having recently load-tested the application we are developing I noticed that
one of the most expensive (time-wise) calls was my fetch of a db-connection
from the defined db-pool. At present I fetch my connections using :
private Connection getConnection() throws SQLException {
try {
Context jndiCntx = new InitialContext();
DataSource ds =
(DataSource)
jndiCntx.lookup("java:comp/env/jdbc/txDatasource");
return ds.getConnection();
} catch (NamingException ne) {
myLog.error(this.makeSQLInsertable("getConnection - could not
find connection"));
throw new EJBException(ne);
In other parts of the code, not developed by the same team, I've seen the
same task accomplished by :
private Connection getConnection() throws SQLException {
return DriverManager.getConnection("jdbc:weblogic:jts:FTPool");
From the performance-measurements I made the latter seems to be much more
efficient (time-wise). To give you some metrics:
The first version took a total of 75724ms for a total of 7224 calls which
gives ~ 11ms/call
The second version took a total of 8127ms for 11662 calls which gives
~0,7ms/call
I'm no JDBC guru som i'm probably missing something vital here. One
suspicion I have is that the second call first find the jdbc-pool and after
that makes the very same (DataSource)
jndiCntx.lookup("java:comp/env/jdbc/txDatasource") in order to fetch the
actual connection anyway. If that is true then my comparison is plain wrong
since one call is part of the second. If not, then the second version sure
seems a lot faster.
Apart from the obvious performance-differences in the two above approaches,
is there any other difference one should be aware of (transaction-context
for instance) between the two ? Basically I'm working in an EJB-environment
on weblogic 7.0 and looking for the most efficient way to get hold of a
db-connection in code. Comments anyone ?
//Linus Nikander - [email protected]

Answer 1

Linus Nikander wrote:
Thank you for both your replies. As per your suggestions I've improved my
connectionhandling (I ended up implementing the Service Locator pattern as a
matter of fact).
One thing still puzzles me though. Which (and why) is the "proper" way to
fetch the actual dataSource. As I stated before in the code I've seen two
approaches within the code I've got.
1. myDs = myServiceLocator.getDataSource("jdbc:weblogic:jts:FTPool");
2. myDs = myServiceLocator.getDataSource("java:comp/env/jdbc/tgsDB");
where getDataSource does a dataSource = (DataSource)
initialContext.lookup(dataSourceName); dataSourceName being the input-string
obviously.
tgsDB is defined as
<reference-descriptor>
<resource-description>
<res-ref-name>jdbc/tgsDB</res-ref-name>
<jndi-name>tgs-dataSource</jndi-name>
</resource-description>
</reference-descriptor>
in weblogic-ejb-jar.xml
From what I can understand by your answer, you don't recommend using the
JNDI-lookup way of getting the connection at all ?Correct.
The service locator that
I implemented will still perform a JNDI lookup, but only once. Will the fact
that I'm talking to an RMI-object anyway significantly impact performance
(when compared to you non-jndi-method) ?In some cases, for earlier 7.0s, maybe yes. For the very latest, it shouldn't
hurt.
>
>
In my two examples above. If i use version 1. How will the server know
whether to give me a TX-bound connection and when not to ? In version 1
FTPool maps to a pool with both TX and non-TX datasources. In version 2.
tgsDB maps directly to a TX-dataSource.
I might be asking a lot of strange questions, probably because I'm just
getting the hang of all the resource-reference issues that EJBs are
associated with.Bear with me ;)
//Linus
"Joseph Weinstein" <[email protected]> wrote in message
news:[email protected]...
Hi. As Jon said, the lookups are redundant. Because you showed that otherway,
I will infer that this code is always being run in serverside code. Good.I will give you
a third way which is much better than either of the ones you showed. Thefirst method
you showed has a problem for all but the latest sps, your jdbc objectswill all be
going through an unnecessary level of indirection because you are gettingan rmi jdbc
object which talks to the jts driver object.
The second, faster method you showed also has a serious problem! Oneshould
never call DriverManager methods in multithreaded JDBC programs becauseall
DriverManager calls are class-synchronized, including some small internalones like
DriverManager.println(), which all JDBC drivers and even the constructorfor
SQLException call, so one slow getConnection() call can inadvertantly haltall other
JDBC being done in the whole JVM! Also, for JVMs that have lots of jdbcdrivers
registered, DriverManager is inefficient because it simply sends your URLand
properties to every driver it has registered until it finds one thatdoesn't throw an
exception and returns a connection.
Here's the fastest way:
// do once and reuse driver object everywhere. Can be used by multiplethreads
Driver d =(Driver)Class.forName("weblogic.jdbc.jts.Driver").newInstance();
Then, whenever you want a connection:
public myJDBCMethod()
Connection c = null; // always a method level object
try {
c = d.connect("jdbc:weblogic:jts:FTPool", null);
... do all the jdbc for the method...
c.close();
c = null;
catch (Exception e) {
... do whatever, if needed...
finally {
// close connection regardless of failure or exit path
if (c != null) try {c.close();}catch (Exception ignore){}
Joe
Linus Nikander wrote:
Having recently load-tested the application we are developing I noticed
that
one of the most expensive (time-wise) calls was my fetch of adb-connection
from the defined db-pool. At present I fetch my connections using :
private Connection getConnection() throws SQLException {
try {
Context jndiCntx = new InitialContext();
DataSource ds =
(DataSource)
jndiCntx.lookup("java:comp/env/jdbc/txDatasource");
return ds.getConnection();
} catch (NamingException ne) {
myLog.error(this.makeSQLInsertable("getConnection - couldnot
find connection"));
throw new EJBException(ne);
In other parts of the code, not developed by the same team, I've seenthe
same task accomplished by :
private Connection getConnection() throws SQLException {
return DriverManager.getConnection("jdbc:weblogic:jts:FTPool");
From the performance-measurements I made the latter seems to be muchmore
efficient (time-wise). To give you some metrics:
The first version took a total of 75724ms for a total of 7224 callswhich
gives ~ 11ms/call
The second version took a total of 8127ms for 11662 calls which gives
~0,7ms/call
I'm no JDBC guru som i'm probably missing something vital here. One
suspicion I have is that the second call first find the jdbc-pool andafter
that makes the very same (DataSource)
jndiCntx.lookup("java:comp/env/jdbc/txDatasource") in order to fetch the
actual connection anyway. If that is true then my comparison is plainwrong
since one call is part of the second. If not, then the second versionsure
seems a lot faster.
Apart from the obvious performance-differences in the two aboveapproaches,
is there any other difference one should be aware of(transaction-context
for instance) between the two ? Basically I'm working in anEJB-environment
on weblogic 7.0 and looking for the most efficient way to get hold of a
db-connection in code. Comments anyone ?
//Linus Nikander - [email protected]