You are viewing a plain text version of this content. The canonical link for it is here.
Posted to -deprecated@jakarta.apache.org by "Waldhoff, Rodney" <rw...@us.britannica.com> on 2001/03/05 18:57:27 UTC
[DBCP] Let's Get Started
All,
This may be jumping the gun just a little bit, but I've got external
deadlines that are putting pressure on me to get this resolved.
The back story, for those who haven't heard it:
A couple of months ago, at the company I work for we ran into problems with
the connection pooling implementation within the commercial product we were
using. Specifically, (a) the pool itself was buggy and (b) the pool
implementation made it difficult for us to pool PreparedStatements and the
parse rate of unpooled PreparedStatements within the database was becoming a
bottleneck to application performance. For this reason I put together a
Connection/PreparedStatement pooling implementation that met our needs.
Completely independently, I noticed the Struts project on
jakarta.apache.org, started to poke around a bit, and subscribed to
struts-dev and struts-user. I noticed that Struts had a basic connection
pooling implementation. I also noticed several requests on struts-dev and
struts-user looking to expand the functionality on the Struts connection
pool. Many of the features (in fact all of the features) that were being
asked for were/are features of the Connection/PreparedStatement pool I put
together. Noting that there is nothing particularly proprietary about the
connection pooling mechanism I put together, I repackaged my code as
org.apache.struts.*, and submitted it to the list.
Since there is at least one other Java-based connection pooling
implementation available in the Apache world, that opened up a big can of
worms. Actually, I'd like to think of that as a Good Thing, since that's at
least a small part of what led us to here.
In any event, I have a demonstrated need for a connection pooling library
that supports (in addition to the basic configurable connection pooling, of
course):
a) PreparedStatement pooling
b) a pseudo-Driver interface
c) a DataSource interface
The connection pooling implementation I submitted to struts a while back
supports these features, and is based upon code that performs quite well for
us in a high-traffic (top 100 ;)), database-intensive, production
environment. I've placed the source "jar-ball", and a couple of links to my
original struts posts at http://www.webappcabaret.com/rwald/dbcp/. If you
are interested, feel free to poke around.
A few of comments on that bundle:
1. Everything is packaged as org.apache.struts.*. I fully expect that to
change, but I don't know what to, so I just left it as is for now.
2. The database connection pool sort of assumes a simple but generic object
pooling library (that I packaged as org.apache.struts.util.pool.*) which in
turn assumes a "generic" CursorableLinkedList (that I packaged as
org.apache.struts.util). I stand by the notion that the connection pool is
nothing more than an extension to a generic pooling mechanism, but I'm
willing to make it stand-alone at first, and refactor to use the common
object pooling library whenever we reach consensus on that.
3. There is no build.xml, because it worked as-is with an unmodified struts
build.xml. Nothing fancy is required, straight javac and javadoc work fine.
4. There is a small example of how to use it in one of the linked posts.
The javadoc comments have some additional information as well.
As I mentioned above, we've got a new major release coming up that I'd like
to roll the Apache connection pooling module into, and there are some
additional features I'd like to add to the existing pool implementation
(optionally tracking the number of connections borrowed by a thread at one
time, for example). Ideally the Apache DBCP module will come together in
time for me do this, so this email is intended to jump-start that process.
I'm not married to this implementation (although we've been pretty happy
with it so far). I'd be happy to use a different starting point if someone
has one they'd like to offer up, or to integrate with other implementations
in the short or long run. I just need some kind of connection pool that
supports the three features mentioned above, and I'd like it sooner rather
than later.
Questions, comments or complaints are welcome. I specifically invite input
on:
i. Do others find this to be a reasonable starting point?
ii. How should this be packaged?
iii. What's next? If others have mods they'd like to suggest, I could
update the JAR directly, or move it all to some Apache CVS or to SourceForge
for the time being.
- Rod
Re: [DBCP] Let's Get Started
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
As you say - let's get started!
I had similar motivation - needed one, saw struts et al. The biggies
for me were a Driver interface and DataSource. If PreparedStatement
pooling lights your lucky, I'm all for it...
I hope to get snowed in tomorrow - I will try to look at what you have.
Count me in.
geir
"Waldhoff, Rodney" wrote:
>
> All,
>
> This may be jumping the gun just a little bit, but I've got external
> deadlines that are putting pressure on me to get this resolved.
>
> The back story, for those who haven't heard it:
>
> A couple of months ago, at the company I work for we ran into problems with
> the connection pooling implementation within the commercial product we were
> using. Specifically, (a) the pool itself was buggy and (b) the pool
> implementation made it difficult for us to pool PreparedStatements and the
> parse rate of unpooled PreparedStatements within the database was becoming a
> bottleneck to application performance. For this reason I put together a
> Connection/PreparedStatement pooling implementation that met our needs.
>
> Completely independently, I noticed the Struts project on
> jakarta.apache.org, started to poke around a bit, and subscribed to
> struts-dev and struts-user. I noticed that Struts had a basic connection
> pooling implementation. I also noticed several requests on struts-dev and
> struts-user looking to expand the functionality on the Struts connection
> pool. Many of the features (in fact all of the features) that were being
> asked for were/are features of the Connection/PreparedStatement pool I put
> together. Noting that there is nothing particularly proprietary about the
> connection pooling mechanism I put together, I repackaged my code as
> org.apache.struts.*, and submitted it to the list.
>
> Since there is at least one other Java-based connection pooling
> implementation available in the Apache world, that opened up a big can of
> worms. Actually, I'd like to think of that as a Good Thing, since that's at
> least a small part of what led us to here.
>
> In any event, I have a demonstrated need for a connection pooling library
> that supports (in addition to the basic configurable connection pooling, of
> course):
>
> a) PreparedStatement pooling
>
> b) a pseudo-Driver interface
>
> c) a DataSource interface
>
> The connection pooling implementation I submitted to struts a while back
> supports these features, and is based upon code that performs quite well for
> us in a high-traffic (top 100 ;)), database-intensive, production
> environment. I've placed the source "jar-ball", and a couple of links to my
> original struts posts at http://www.webappcabaret.com/rwald/dbcp/. If you
> are interested, feel free to poke around.
>
> A few of comments on that bundle:
>
> 1. Everything is packaged as org.apache.struts.*. I fully expect that to
> change, but I don't know what to, so I just left it as is for now.
>
> 2. The database connection pool sort of assumes a simple but generic object
> pooling library (that I packaged as org.apache.struts.util.pool.*) which in
> turn assumes a "generic" CursorableLinkedList (that I packaged as
> org.apache.struts.util). I stand by the notion that the connection pool is
> nothing more than an extension to a generic pooling mechanism, but I'm
> willing to make it stand-alone at first, and refactor to use the common
> object pooling library whenever we reach consensus on that.
>
> 3. There is no build.xml, because it worked as-is with an unmodified struts
> build.xml. Nothing fancy is required, straight javac and javadoc work fine.
>
> 4. There is a small example of how to use it in one of the linked posts.
> The javadoc comments have some additional information as well.
>
> As I mentioned above, we've got a new major release coming up that I'd like
> to roll the Apache connection pooling module into, and there are some
> additional features I'd like to add to the existing pool implementation
> (optionally tracking the number of connections borrowed by a thread at one
> time, for example). Ideally the Apache DBCP module will come together in
> time for me do this, so this email is intended to jump-start that process.
>
> I'm not married to this implementation (although we've been pretty happy
> with it so far). I'd be happy to use a different starting point if someone
> has one they'd like to offer up, or to integrate with other implementations
> in the short or long run. I just need some kind of connection pool that
> supports the three features mentioned above, and I'd like it sooner rather
> than later.
>
> Questions, comments or complaints are welcome. I specifically invite input
> on:
>
> i. Do others find this to be a reasonable starting point?
>
> ii. How should this be packaged?
>
> iii. What's next? If others have mods they'd like to suggest, I could
> update the JAR directly, or move it all to some Apache CVS or to SourceForge
> for the time being.
>
> - Rod
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/
Re: [DBCP] Let's Get Started
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Ted Husted wrote:
> "Waldhoff, Rodney" wrote:
> > In any event, I have a demonstrated need for a connection pooling library
> > that supports (in addition to the basic configurable connection pooling, of
> > course):
> >
> > a) PreparedStatement pooling
> >
> > b) a pseudo-Driver interface
> >
> > c) a DataSource interface
>
> The hottest button on the Struts list seemed to be "connection
> collection", and I see this implementation does do this. This means when
> used on a multi-application server, it will play nice, and release
> connections it is not actively using (so someone else can connection to
> the DBMS instead).
>
Yah, that part looks nice but I haven't played with it yet.
>
> I imagine it is also able to instantiate multiple pools with various
> logins, so that you could create a connection pool to another DBMS, or a
> pool with different access rights, et cetera.
>
> > i. Do others find this to be a reasonable starting point?
>
> +0 = Looks good, but I need to try and hook this up to a test
> application of my own. I'd also like to try it with Morgan's JDBC
> taglib. Any quickstart instructions on hooking it up to Struts?
>
> > ii. How should this be packaged?
>
> I'd say < org.apache.common.DBCP > for now.
>
If the project is "commons", shouldn't that be the package name? Also, I dislike
all-caps package names, so I would suggest:
org.apache.commons.dbcp
which reminds me, the next step in discussion is to talk about how the CVS source
repository should be organized ... but that's a subproject-specific discussion
after the general mail list gets created.
>
> > iii. What's next? If others have mods they'd like to suggest, I could
> > update the JAR directly, or move it all to some Apache CVS or to SourceForge
> > for the time being.
>
> If you can coordinate any patches, let's see if we can work around
> putting it in a CVS until the vote goes through, then hopefully we can
> put it in our own ;-)
>
Several people have expressed interest in the Struts bean introspection classes --
a small package of classes that depend only on the JDK -- I will propose that as
soon as we have a real subproject. (It's also a prereq for the Struts version of
an XML processor for config files.)
>
> Let's not forget how Apache got it's name ;-)
>
> -Ted.
Craig
Re: [DBCP] Let's Get Started
Posted by "Craig R. McClanahan" <Cr...@eng.sun.com>.
Ted Husted wrote:
> "Waldhoff, Rodney" wrote:
> > In any event, I have a demonstrated need for a connection pooling library
> > that supports (in addition to the basic configurable connection pooling, of
> > course):
> >
> > a) PreparedStatement pooling
> >
> > b) a pseudo-Driver interface
> >
> > c) a DataSource interface
>
> The hottest button on the Struts list seemed to be "connection
> collection", and I see this implementation does do this. This means when
> used on a multi-application server, it will play nice, and release
> connections it is not actively using (so someone else can connection to
> the DBMS instead).
>
Yah, that part looks nice but I haven't played with it yet.
>
> I imagine it is also able to instantiate multiple pools with various
> logins, so that you could create a connection pool to another DBMS, or a
> pool with different access rights, et cetera.
>
> > i. Do others find this to be a reasonable starting point?
>
> +0 = Looks good, but I need to try and hook this up to a test
> application of my own. I'd also like to try it with Morgan's JDBC
> taglib. Any quickstart instructions on hooking it up to Struts?
>
> > ii. How should this be packaged?
>
> I'd say < org.apache.common.DBCP > for now.
>
If the project is "commons", shouldn't that be the package name? Also, I dislike
all-caps package names, so I would suggest:
org.apache.commons.dbcp
which reminds me, the next step in discussion is to talk about how the CVS source
repository should be organized ... but that's a subproject-specific discussion
after the general mail list gets created.
>
> > iii. What's next? If others have mods they'd like to suggest, I could
> > update the JAR directly, or move it all to some Apache CVS or to SourceForge
> > for the time being.
>
> If you can coordinate any patches, let's see if we can work around
> putting it in a CVS until the vote goes through, then hopefully we can
> put it in our own ;-)
>
Several people have expressed interest in the Struts bean introspection classes --
a small package of classes that depend only on the JDK -- I will propose that as
soon as we have a real subproject. (It's also a prereq for the Struts version of
an XML processor for config files.)
>
> Let's not forget how Apache got it's name ;-)
>
> -Ted.
Craig
Re: [DBCP] Let's Get Started
Posted by Ted Husted <ne...@husted.com>.
"Waldhoff, Rodney" wrote:
> In any event, I have a demonstrated need for a connection pooling library
> that supports (in addition to the basic configurable connection pooling, of
> course):
>
> a) PreparedStatement pooling
>
> b) a pseudo-Driver interface
>
> c) a DataSource interface
The hottest button on the Struts list seemed to be "connection
collection", and I see this implementation does do this. This means when
used on a multi-application server, it will play nice, and release
connections it is not actively using (so someone else can connection to
the DBMS instead).
I imagine it is also able to instantiate multiple pools with various
logins, so that you could create a connection pool to another DBMS, or a
pool with different access rights, et cetera.
> i. Do others find this to be a reasonable starting point?
+0 = Looks good, but I need to try and hook this up to a test
application of my own. I'd also like to try it with Morgan's JDBC
taglib. Any quickstart instructions on hooking it up to Struts?
> ii. How should this be packaged?
I'd say < org.apache.common.DBCP > for now.
> iii. What's next? If others have mods they'd like to suggest, I could
> update the JAR directly, or move it all to some Apache CVS or to SourceForge
> for the time being.
If you can coordinate any patches, let's see if we can work around
putting it in a CVS until the vote goes through, then hopefully we can
put it in our own ;-)
Let's not forget how Apache got it's name ;-)
-Ted.
Re: [DBCP] Let's Get Started
Posted by Ted Husted <ne...@husted.com>.
"Waldhoff, Rodney" wrote:
> In any event, I have a demonstrated need for a connection pooling library
> that supports (in addition to the basic configurable connection pooling, of
> course):
>
> a) PreparedStatement pooling
>
> b) a pseudo-Driver interface
>
> c) a DataSource interface
The hottest button on the Struts list seemed to be "connection
collection", and I see this implementation does do this. This means when
used on a multi-application server, it will play nice, and release
connections it is not actively using (so someone else can connection to
the DBMS instead).
I imagine it is also able to instantiate multiple pools with various
logins, so that you could create a connection pool to another DBMS, or a
pool with different access rights, et cetera.
> i. Do others find this to be a reasonable starting point?
+0 = Looks good, but I need to try and hook this up to a test
application of my own. I'd also like to try it with Morgan's JDBC
taglib. Any quickstart instructions on hooking it up to Struts?
> ii. How should this be packaged?
I'd say < org.apache.common.DBCP > for now.
> iii. What's next? If others have mods they'd like to suggest, I could
> update the JAR directly, or move it all to some Apache CVS or to SourceForge
> for the time being.
If you can coordinate any patches, let's see if we can work around
putting it in a CVS until the vote goes through, then hopefully we can
put it in our own ;-)
Let's not forget how Apache got it's name ;-)
-Ted.
Re: [DBCP] Let's Get Started
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
As you say - let's get started!
I had similar motivation - needed one, saw struts et al. The biggies
for me were a Driver interface and DataSource. If PreparedStatement
pooling lights your lucky, I'm all for it...
I hope to get snowed in tomorrow - I will try to look at what you have.
Count me in.
geir
"Waldhoff, Rodney" wrote:
>
> All,
>
> This may be jumping the gun just a little bit, but I've got external
> deadlines that are putting pressure on me to get this resolved.
>
> The back story, for those who haven't heard it:
>
> A couple of months ago, at the company I work for we ran into problems with
> the connection pooling implementation within the commercial product we were
> using. Specifically, (a) the pool itself was buggy and (b) the pool
> implementation made it difficult for us to pool PreparedStatements and the
> parse rate of unpooled PreparedStatements within the database was becoming a
> bottleneck to application performance. For this reason I put together a
> Connection/PreparedStatement pooling implementation that met our needs.
>
> Completely independently, I noticed the Struts project on
> jakarta.apache.org, started to poke around a bit, and subscribed to
> struts-dev and struts-user. I noticed that Struts had a basic connection
> pooling implementation. I also noticed several requests on struts-dev and
> struts-user looking to expand the functionality on the Struts connection
> pool. Many of the features (in fact all of the features) that were being
> asked for were/are features of the Connection/PreparedStatement pool I put
> together. Noting that there is nothing particularly proprietary about the
> connection pooling mechanism I put together, I repackaged my code as
> org.apache.struts.*, and submitted it to the list.
>
> Since there is at least one other Java-based connection pooling
> implementation available in the Apache world, that opened up a big can of
> worms. Actually, I'd like to think of that as a Good Thing, since that's at
> least a small part of what led us to here.
>
> In any event, I have a demonstrated need for a connection pooling library
> that supports (in addition to the basic configurable connection pooling, of
> course):
>
> a) PreparedStatement pooling
>
> b) a pseudo-Driver interface
>
> c) a DataSource interface
>
> The connection pooling implementation I submitted to struts a while back
> supports these features, and is based upon code that performs quite well for
> us in a high-traffic (top 100 ;)), database-intensive, production
> environment. I've placed the source "jar-ball", and a couple of links to my
> original struts posts at http://www.webappcabaret.com/rwald/dbcp/. If you
> are interested, feel free to poke around.
>
> A few of comments on that bundle:
>
> 1. Everything is packaged as org.apache.struts.*. I fully expect that to
> change, but I don't know what to, so I just left it as is for now.
>
> 2. The database connection pool sort of assumes a simple but generic object
> pooling library (that I packaged as org.apache.struts.util.pool.*) which in
> turn assumes a "generic" CursorableLinkedList (that I packaged as
> org.apache.struts.util). I stand by the notion that the connection pool is
> nothing more than an extension to a generic pooling mechanism, but I'm
> willing to make it stand-alone at first, and refactor to use the common
> object pooling library whenever we reach consensus on that.
>
> 3. There is no build.xml, because it worked as-is with an unmodified struts
> build.xml. Nothing fancy is required, straight javac and javadoc work fine.
>
> 4. There is a small example of how to use it in one of the linked posts.
> The javadoc comments have some additional information as well.
>
> As I mentioned above, we've got a new major release coming up that I'd like
> to roll the Apache connection pooling module into, and there are some
> additional features I'd like to add to the existing pool implementation
> (optionally tracking the number of connections borrowed by a thread at one
> time, for example). Ideally the Apache DBCP module will come together in
> time for me do this, so this email is intended to jump-start that process.
>
> I'm not married to this implementation (although we've been pretty happy
> with it so far). I'd be happy to use a different starting point if someone
> has one they'd like to offer up, or to integrate with other implementations
> in the short or long run. I just need some kind of connection pool that
> supports the three features mentioned above, and I'd like it sooner rather
> than later.
>
> Questions, comments or complaints are welcome. I specifically invite input
> on:
>
> i. Do others find this to be a reasonable starting point?
>
> ii. How should this be packaged?
>
> iii. What's next? If others have mods they'd like to suggest, I could
> update the JAR directly, or move it all to some Apache CVS or to SourceForge
> for the time being.
>
> - Rod
--
Geir Magnusson Jr. geirm@optonline.com
Developing for the web? See http://jakarta.apache.org/velocity/