RE: Re[2]: DBCP speed of lookup -vs- stored reference to Datasource?
The best way to avoid the double checke locking issue is just not to use it. Before trying to implement 'double checked locking' right, you have to understand the purpose. The goal was to reduce synchronized access to achieve more performance. (Did you have another rationale ?) In most cases it's just enough to remove the outer if. Also look at: http://www.javaworld.com/javaworld/jw-11-2001/jw-1116-dcl.html (This article also states that ThreadLocal works even slower before JDK 1.4) -Original Message- From: Jacob Kjome [mailto:hoju;visi.com] Sent: Tuesday, October 29, 2002 5:12 AM To: Tomcat Users List Cc: Craig R. McClanahan Subject: Re[2]: DBCP speed of lookup -vs- stored reference to Datasource? I was just making an attempt to avoid the Double-Checked Locking issue and the article http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html under the title Fixing Double-Checked Locking using Thread Local Storage provided an issue that they said worked. Maybe you could provide an example showing me what you would do to create a proper static singleton that doesn't suffer from the Double-Checked Locking issue without resorting to the ThreadLocal solution? -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re[4]: DBCP speed of lookup -vs- stored reference to Datasource?
Hello Ralph, Well, supposedly, everything slowed down in the j2sdk1.4.0 release. The j2sdk1.4.1 release fixed a *ton* of performance regressions that occurred between jdk1.3.x and j2sdk1.4.0. So, I think the jury is still out on whether ThreadLocal is still slow in j2sdk1.4.1. And yes, the goal is to reduce synchronized access to improve performance. If I do remove the outer if using the old way that I had things set up, wouldn't that now make it so I *do* incur the excessive synchronization performance hit? ThreadLocal, if it works speedily in j2sdk1.4.1, should solve that, should it not? Jake Tuesday, October 29, 2002, 2:40:16 AM, you wrote: RE The best way to avoid the double checke locking issue RE is just not to use it. RE Before trying to implement 'double checked locking' right, RE you have to understand the purpose. RE The goal was to reduce synchronized access to achieve more RE performance. (Did you have another rationale ?) RE In most cases it's just enough to remove the outer if. RE Also look at: RE http://www.javaworld.com/javaworld/jw-11-2001/jw-1116-dcl.html RE (This article also states that ThreadLocal works even slower RE before JDK 1.4) -Original Message- From: Jacob Kjome [mailto:hoju;visi.com] Sent: Tuesday, October 29, 2002 5:12 AM To: Tomcat Users List Cc: Craig R. McClanahan Subject: Re[2]: DBCP speed of lookup -vs- stored reference to Datasource? I was just making an attempt to avoid the Double-Checked Locking issue and the article http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html under the title Fixing Double-Checked Locking using Thread Local Storage provided an issue that they said worked. Maybe you could provide an example showing me what you would do to create a proper static singleton that doesn't suffer from the Double-Checked Locking issue without resorting to the ThreadLocal solution? RE -- RE To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org RE For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- Best regards, Jacobmailto:hoju;visi.com -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re[5]: DBCP speed of lookup -vs- stored reference to Datasource?
Whooops. I had read the following: RE (This article also states that ThreadLocal works even slower RE before JDK 1.4) as This article also states that ThreadLocal works even slower [than] before [in] JDK 1.4. So, I thought you were saying that the implementation of ThreadLocal was slower in j2sdk1.4.0 than in 1.3.1. I accepted that idea because I know of a number of performance regression fixes between j2sdk1.4.0 and j2sdk1.4.1. Well, either way, I use j2sdk1.4.1 which should be even faster than 1.4.0 and if the author thinks that 1.4.0 has performance gains over the alternative of running through the syncronized block every time, then it looks like I am doing the most optimized thing I can do by using ThreadLocal. Now, the only other consideration is whether I want to be able to modify the configuration of the DataSource at runtime using the Tomcat Admin app. If that is the case, then I'd throw out all the synchronization stuff and just use query the InitialContext every time for the DataSource object. Craig seemed to think that solution would be pretty fast and provide flexibility. I will definitely consider it. Jake Tuesday, October 29, 2002, 11:49:23 AM, you wrote: JK Hello Ralph, JK Well, supposedly, everything slowed down in the j2sdk1.4.0 release. JK The j2sdk1.4.1 release fixed a *ton* of performance regressions that JK occurred between jdk1.3.x and j2sdk1.4.0. So, I think the jury is JK still out on whether ThreadLocal is still slow in j2sdk1.4.1. JK And yes, the goal is to reduce synchronized access to improve JK performance. If I do remove the outer if using the old way that I had JK things set up, wouldn't that now make it so I *do* incur the JK excessive synchronization performance hit? ThreadLocal, if it works JK speedily in j2sdk1.4.1, should solve that, should it not? JK Jake JK Tuesday, October 29, 2002, 2:40:16 AM, you wrote: RE The best way to avoid the double checke locking issue RE is just not to use it. RE Before trying to implement 'double checked locking' right, RE you have to understand the purpose. RE The goal was to reduce synchronized access to achieve more RE performance. (Did you have another rationale ?) RE In most cases it's just enough to remove the outer if. RE Also look at: RE http://www.javaworld.com/javaworld/jw-11-2001/jw-1116-dcl.html RE (This article also states that ThreadLocal works even slower RE before JDK 1.4) -Original Message- From: Jacob Kjome [mailto:hoju;visi.com] Sent: Tuesday, October 29, 2002 5:12 AM To: Tomcat Users List Cc: Craig R. McClanahan Subject: Re[2]: DBCP speed of lookup -vs- stored reference to Datasource? I was just making an attempt to avoid the Double-Checked Locking issue and the article http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html under the title Fixing Double-Checked Locking using Thread Local Storage provided an issue that they said worked. Maybe you could provide an example showing me what you would do to create a proper static singleton that doesn't suffer from the Double-Checked Locking issue without resorting to the ThreadLocal solution? RE -- RE To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org RE For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- Best regards, Jacobmailto:hoju;visi.com -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
DBCP speed of lookup -vs- stored reference to Datasource?
I'm wondering what kind of performance penalty there is, if any, when doing
a full lookup of the Datasource object each and every time through JNDI
calls? Basically, does it make sense to do one lookup and store a local
copy for future use? The one problem I see with doing that is that if one
ever wants to use the Tomcat Manager app to modify configuration on the
fly, using the local copy of the Datasource would make it so you never
really realize that a change to configuration has been made. Am I simply
losing flexibility without gaining any performance?
The way I have the lookup performed is the following. Please let me know
if this is totally unnecessary
final class MyDataSourceClass {
private static DataSource ds = null;
public static Boolean DS_INITIALIZED = Boolean.FALSE;
public static Connection getConnection() throws SQLException {
if (DS_INITIALIZED.equals(Boolean.FALSE) || ds == null) {
synchronized (DS_INITIALIZED) {
if (DS_INITIALIZED.equals(Boolean.FALSE) || ds == null) {
try {
Context ctx = new InitialContext();
ds =
(DataSource)ctx.lookup(java:comp/env/jdbc/myDB);
if (ds == null) throw new SQLException(No
DataSource available for Connection);
DS_INITIALIZED = Boolean.TRUE;
}
catch (NamingException ne) {
throw new SQLException(JNDI Lookup Failed: +
ne.getMessage());
}
}
}
}
return ds.getConnection();
}
public static void returnConnection(Connection conn) throws SQLException {
conn.close();
}
}
So, basically I want to know if the lookup isn't expensive enough to bother
with storing the DataSource locally.
thanks,
Jake
--
To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
RE: DBCP speed of lookup -vs- stored reference to Datasource?
Not really related to your question, but to your code:
The use of the synchronized as you do it, is not
recommended.
Don't try to optize the synchnized block by wrapping
it in a if. There is no garantee that this will work
as intended. Have a look at the references in:
http://www.javaworld.com/javaworld/javaqa/2002-04/01-qa-0412-doublelock.html
-Original Message-
From: Jacob Kjome [mailto:hoju;visi.com]
Sent: Monday, October 28, 2002 3:08 PM
To: Tomcat Users List
Subject: DBCP speed of lookup -vs- stored reference to Datasource?
if (DS_INITIALIZED.equals(Boolean.FALSE) || ds == null) {
synchronized (DS_INITIALIZED) {
if (DS_INITIALIZED.equals(Boolean.FALSE) || ds == null) {
}
}
}
--
To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: DBCP speed of lookup -vs- stored reference to Datasource?
On Mon, 28 Oct 2002, Jacob Kjome wrote:
Date: Mon, 28 Oct 2002 08:08:09 -0600
From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: DBCP speed of lookup -vs- stored reference to Datasource?
I'm wondering what kind of performance penalty there is, if any, when doing
a full lookup of the Datasource object each and every time through JNDI
calls? Basically, does it make sense to do one lookup and store a local
copy for future use? The one problem I see with doing that is that if one
ever wants to use the Tomcat Manager app to modify configuration on the
fly, using the local copy of the Datasource would make it so you never
really realize that a change to configuration has been made. Am I simply
losing flexibility without gaining any performance?
The JNDI lookup, after some manipulations of the name, turns into a
HashMap lookup inside the server. It's not particularly expensive -- and
isn't even worth looking at (from a performance perspective) unless you've
already tuned all your database queries for maximum performance. That's
where the vast majority of problems occur.
Performance aside, there are two functionality reasons to do the lookup
every time:
* Keeping a reference to the data source yourself means that
you need to either pass it on to every method, or make it
available some other way. The lookup code requires zero references
to things like the ServletContext or any static variables.
* In a high-available application server environment (i.e. Tomcat
by itself doesn't support this), doing the lookup every time gives
the server an opportunity to gracefully deal with things like
switching to a backup database, or dynamically reconfiguring the
connection pool by giving you a new instance from now on.
The way I have the lookup performed is the following. Please let me know
if this is totally unnecessary
final class MyDataSourceClass {
private static DataSource ds = null;
public static Boolean DS_INITIALIZED = Boolean.FALSE;
public static Connection getConnection() throws SQLException {
if (DS_INITIALIZED.equals(Boolean.FALSE) || ds == null) {
synchronized (DS_INITIALIZED) {
if (DS_INITIALIZED.equals(Boolean.FALSE) || ds == null) {
try {
Context ctx = new InitialContext();
ds =
(DataSource)ctx.lookup(java:comp/env/jdbc/myDB);
if (ds == null) throw new SQLException(No
DataSource available for Connection);
DS_INITIALIZED = Boolean.TRUE;
}
catch (NamingException ne) {
throw new SQLException(JNDI Lookup Failed: +
ne.getMessage());
}
}
}
}
return ds.getConnection();
}
public static void returnConnection(Connection conn) throws SQLException {
conn.close();
}
}
So, basically I want to know if the lookup isn't expensive enough to bother
with storing the DataSource locally.
As others will undoubtedly point out, the Double-Checked Locking
algorithm you use above is not guaranteed to work. There was a JavaWorld
article on this topic last year.
thanks,
Jake
Craig
--
To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org
For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re[2]: DBCP speed of lookup -vs- stored reference to Datasource?
Hello Craig,
seem comments inline below
Monday, October 28, 2002, 12:14:05 PM, you wrote:
CRM On Mon, 28 Oct 2002, Jacob Kjome wrote:
Date: Mon, 28 Oct 2002 08:08:09 -0600
From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: DBCP speed of lookup -vs- stored reference to Datasource?
I'm wondering what kind of performance penalty there is, if any, when doing
a full lookup of the Datasource object each and every time through JNDI
calls? Basically, does it make sense to do one lookup and store a local
copy for future use? The one problem I see with doing that is that if one
ever wants to use the Tomcat Manager app to modify configuration on the
fly, using the local copy of the Datasource would make it so you never
really realize that a change to configuration has been made. Am I simply
losing flexibility without gaining any performance?
CRM The JNDI lookup, after some manipulations of the name, turns into a
CRM HashMap lookup inside the server. It's not particularly expensive -- and
CRM isn't even worth looking at (from a performance perspective) unless you've
CRM already tuned all your database queries for maximum performance. That's
CRM where the vast majority of problems occur.
CRM Performance aside, there are two functionality reasons to do the lookup
CRM every time:
CRM * Keeping a reference to the data source yourself means that
CRM you need to either pass it on to every method, or make it
CRM available some other way. The lookup code requires zero references
CRM to things like the ServletContext or any static variables.
In my setup, I have data object and a single manager class for each
data object where the queries are actually done. Each manager class
extends Manager which, itself, extends ConnectionManager which
contains the getConnection() and returnConnection(Connection) methods
so holding a static variable in the ConnectionManager isn't all that
big of a deal. I don't have to pass the DataSource around at all. I
just ask for a connection and the stored DataSource returns an
available connection object.
CRM * In a high-available application server environment (i.e. Tomcat
CRM by itself doesn't support this), doing the lookup every time gives
CRM the server an opportunity to gracefully deal with things like
CRM switching to a backup database, or dynamically reconfiguring the
CRM connection pool by giving you a new instance from now on.
Doesn't the Tomcat Admin app support managing DBCP DataSource
configuration? I think I can switch the connection string an other
variables on the fly there. This is the primary reason that I am
interested in whether doing the lookup incurs a performance penalty or
not. Sounds like there isn't really a performance penalty so if Tomcat
could switch the DataSource at runtime, then I'd
continue keeping a local static copy of the DataSource. So, can the
Admin app do this for me or not?
The way I have the lookup performed is the following. Please let me know
if this is totally unnecessary
final class MyDataSourceClass {
private static DataSource ds = null;
public static Boolean DS_INITIALIZED = Boolean.FALSE;
public static Connection getConnection() throws SQLException {
if (DS_INITIALIZED.equals(Boolean.FALSE) || ds == null) {
synchronized (DS_INITIALIZED) {
if (DS_INITIALIZED.equals(Boolean.FALSE) || ds == null) {
try {
Context ctx = new InitialContext();
ds =
(DataSource)ctx.lookup(java:comp/env/jdbc/myDB);
if (ds == null) throw new SQLException(No
DataSource available for Connection);
DS_INITIALIZED = Boolean.TRUE;
}
catch (NamingException ne) {
throw new SQLException(JNDI Lookup Failed: +
ne.getMessage());
}
}
}
}
return ds.getConnection();
}
public static void returnConnection(Connection conn) throws SQLException {
conn.close();
}
}
So, basically I want to know if the lookup isn't expensive enough to bother
with storing the DataSource locally.
CRM As others will undoubtedly point out, the Double-Checked Locking
CRM algorithm you use above is not guaranteed to work. There was a JavaWorld
CRM article on this topic last year.
Yep, this was brought to my attention in a previous post. I have
modified the Double-checking Locking scheme to something that
supposedly works and is safe.
See http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html under the
heading
Fixing Double-Checked Locking using Thread Local Storage
In my case, it is slightly modified since I am using static variables
and a static method:
final class ConnectionManager
Re[2]: DBCP speed of lookup -vs- stored reference to Datasource?
On Mon, 28 Oct 2002, Jacob Kjome wrote:
Date: Mon, 28 Oct 2002 13:04:18 -0600
From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED],
Jacob Kjome [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: Re[2]: DBCP speed of lookup -vs- stored reference to Datasource?
Hello Craig,
seem comments inline below
Monday, October 28, 2002, 12:14:05 PM, you wrote:
CRM On Mon, 28 Oct 2002, Jacob Kjome wrote:
Date: Mon, 28 Oct 2002 08:08:09 -0600
From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: DBCP speed of lookup -vs- stored reference to Datasource?
I'm wondering what kind of performance penalty there is, if any, when doing
a full lookup of the Datasource object each and every time through JNDI
calls? Basically, does it make sense to do one lookup and store a local
copy for future use? The one problem I see with doing that is that if one
ever wants to use the Tomcat Manager app to modify configuration on the
fly, using the local copy of the Datasource would make it so you never
really realize that a change to configuration has been made. Am I simply
losing flexibility without gaining any performance?
CRM The JNDI lookup, after some manipulations of the name, turns into a
CRM HashMap lookup inside the server. It's not particularly expensive -- and
CRM isn't even worth looking at (from a performance perspective) unless you've
CRM already tuned all your database queries for maximum performance. That's
CRM where the vast majority of problems occur.
CRM Performance aside, there are two functionality reasons to do the lookup
CRM every time:
CRM * Keeping a reference to the data source yourself means that
CRM you need to either pass it on to every method, or make it
CRM available some other way. The lookup code requires zero references
CRM to things like the ServletContext or any static variables.
In my setup, I have data object and a single manager class for each
data object where the queries are actually done. Each manager class
extends Manager which, itself, extends ConnectionManager which
contains the getConnection() and returnConnection(Connection) methods
so holding a static variable in the ConnectionManager isn't all that
big of a deal. I don't have to pass the DataSource around at all. I
just ask for a connection and the stored DataSource returns an
available connection object.
But you have to pass a reference to your ConnectionManager around, or
reference it with a static variable, right? That makes any class that
uses this approach dependent on the ConnectionManager class. Business
objects that depend only on the standard JNDI lookups for DataSource have
no external dependencies on anything other than the javax.sql APIs.
It is also not clear to me what value add your ConnectionManager has over
the standard DataSource APIs, but I'm sure there must be something.
CRM * In a high-available application server environment (i.e. Tomcat
CRM by itself doesn't support this), doing the lookup every time gives
CRM the server an opportunity to gracefully deal with things like
CRM switching to a backup database, or dynamically reconfiguring the
CRM connection pool by giving you a new instance from now on.
Doesn't the Tomcat Admin app support managing DBCP DataSource
configuration? I think I can switch the connection string an other
variables on the fly there. This is the primary reason that I am
interested in whether doing the lookup incurs a performance penalty or
not. Sounds like there isn't really a performance penalty so if Tomcat
could switch the DataSource at runtime, then I'd
continue keeping a local static copy of the DataSource. So, can the
Admin app do this for me or not?
I'd have to look at the sources to see if the dynamic swapout at runtime
actually works or not -- it might well.
The way I have the lookup performed is the following. Please let me know
if this is totally unnecessary
final class MyDataSourceClass {
private static DataSource ds = null;
public static Boolean DS_INITIALIZED = Boolean.FALSE;
public static Connection getConnection() throws SQLException {
if (DS_INITIALIZED.equals(Boolean.FALSE) || ds == null) {
synchronized (DS_INITIALIZED) {
if (DS_INITIALIZED.equals(Boolean.FALSE) || ds == null) {
try {
Context ctx = new InitialContext();
ds =
(DataSource)ctx.lookup(java:comp/env/jdbc/myDB);
if (ds == null) throw new SQLException(No
DataSource available for Connection);
DS_INITIALIZED = Boolean.TRUE;
}
catch (NamingException ne) {
throw new SQLException(JNDI Lookup
Re[2]: DBCP speed of lookup -vs- stored reference to Datasource?
Hi Craig,
See comments inline below...
At 11:23 AM 10/28/2002 -0800, Craig R. McClanahan wrote:
On Mon, 28 Oct 2002, Jacob Kjome wrote:
Date: Mon, 28 Oct 2002 13:04:18 -0600
From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED],
Jacob Kjome [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: Re[2]: DBCP speed of lookup -vs- stored reference to Datasource?
Hello Craig,
seem comments inline below
Monday, October 28, 2002, 12:14:05 PM, you wrote:
CRM On Mon, 28 Oct 2002, Jacob Kjome wrote:
Date: Mon, 28 Oct 2002 08:08:09 -0600
From: Jacob Kjome [EMAIL PROTECTED]
Reply-To: Tomcat Users List [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Subject: DBCP speed of lookup -vs- stored reference to Datasource?
I'm wondering what kind of performance penalty there is, if any,
when doing
a full lookup of the Datasource object each and every time through JNDI
calls? Basically, does it make sense to do one lookup and store a local
copy for future use? The one problem I see with doing that is that
if one
ever wants to use the Tomcat Manager app to modify configuration on the
fly, using the local copy of the Datasource would make it so you never
really realize that a change to configuration has been made. Am I
simply
losing flexibility without gaining any performance?
CRM The JNDI lookup, after some manipulations of the name, turns into a
CRM HashMap lookup inside the server. It's not particularly expensive
-- and
CRM isn't even worth looking at (from a performance perspective)
unless you've
CRM already tuned all your database queries for maximum
performance. That's
CRM where the vast majority of problems occur.
CRM Performance aside, there are two functionality reasons to do the
lookup
CRM every time:
CRM * Keeping a reference to the data source yourself means that
CRM you need to either pass it on to every method, or make it
CRM available some other way. The lookup code requires zero references
CRM to things like the ServletContext or any static variables.
In my setup, I have data object and a single manager class for each
data object where the queries are actually done. Each manager class
extends Manager which, itself, extends ConnectionManager which
contains the getConnection() and returnConnection(Connection) methods
so holding a static variable in the ConnectionManager isn't all that
big of a deal. I don't have to pass the DataSource around at all. I
just ask for a connection and the stored DataSource returns an
available connection object.
But you have to pass a reference to your ConnectionManager around, or
reference it with a static variable, right? That makes any class that
uses this approach dependent on the ConnectionManager class. Business
objects that depend only on the standard JNDI lookups for DataSource have
no external dependencies on anything other than the javax.sql APIs.
It is also not clear to me what value add your ConnectionManager has over
the standard DataSource APIs, but I'm sure there must be something.
You know what, I just re-read what I stated above and that is not quite
correct. I do have a Manager class which the other manager classes extend,
however Manager itself does not extend anything. It just uses the
ConnectionManager as a static singleton. Manager has the following methods
which the other manager classes use to get and close their connections.
protected Connection openConn() throws SQLException {
return ConnectionManager.getConnection();
}
protected void closeConn(Connection _conn) throws SQLException {
ConnectionManager.returnConnection(_conn);
}
My manager classes have no clue as to how the connection gets
created. They just know that by calling those methods, they can get a
close connections. ConnectionManager encapsulates the actual way that the
connection is gotten and I already showed you what my ConnectionManager
looks like. In fact, I can switch it from using a DBCP connection pool via
a DataSource object to any other connection pool. I previously used
BitMechanic's JDBC pool ( http://www.bitmechanic.com/projects/jdbcpool/
). The *only* class I changed in the entire app moving from jdbcpool to
DBCP was the ConnectionManger class and everything just worked
transparently. I'm not the best Java developer in the world, but I do
think I made a pretty decent design decision here. Wouldn't you agree or
am I being naive? What would be better?
CRM * In a high-available application server environment (i.e. Tomcat
CRM by itself doesn't support this), doing the lookup every time gives
CRM the server an opportunity to gracefully deal with things like
CRM switching to a backup database, or dynamically reconfiguring the
CRM connection pool by giving you a new instance from now on.
Doesn't the Tomcat Admin app support managing DBCP DataSource
