open source jdbc pooling

[MileHighCelt]

I am looking for some open source database pooling for my Struts/mySQL
application. I have looked at the db-commons from Apache and proxool
and they seem fine. I have also looked on the Sun site, but didn't
really see anything that was suitable.

I was hoping someone could give me their unbiased opinon on something
lightweight and easy to use. I don't forsee a high user/transaction
load, but performance is key.

Thank you for your advice/opinion

 

[Harry Bosch]

You were in the right place http://jakarta.apache.org/commons/dbcp/

I would say that is your best bet. I believe that it is widely
accepted by many projects, i.e. Tomcat uses it.

 

[Harry Bosch]

Oh, I also wanted to say that if you are using Struts, then you are
(assuming you are writing your own) using some sort of container
(Tomcat, Jetty, Resin, Weblogic, Websphere etc). If this is the case
then you should probably use the pooling that is in the container
itself. You would then set up a "datasource" and use that within the
application. Let the application server handle pooling. You shouldn't
have to do this in your web-app.

 

[Harry Bosch]

Oh, I also wanted to say that if you are using Struts, then you are
(assuming you are writing your own) using some sort of container
(Tomcat, Jetty, Resin, Weblogic, Websphere etc). If this is the case
then you should probably use the pooling that is in the container
itself. You would then set up a "datasource" and use that within the
application. Let the application server handle pooling. You shouldn't
have to do this in your web-app.

 

[jonck]

I am looking for some open source database pooling for my Struts/mySQL

application.

Check out C3P0 at: http://sourceforge.net/projects/c3p0

I found this to be a very nice library; works well, good performance
and very easy to implement.

 

[dnasmars]

I am looking for some open source database pooling for my Struts/mySQL
application. I have looked at the db-commons from Apache and proxool
and they seem fine. I have also looked on the Sun site, but didn't
really see anything that was suitable.

I was hoping someone could give me their unbiased opinon on something
lightweight and easy to use. I don't forsee a high user/transaction
load, but performance is key.

Thank you for your advice/opinion

I find this http://java-source.net/ a gold mine
you can check http://java-source.net/open-source/connection-pools
I personnaly use http://sourceforge.net/projects/yapoolman
it does everything and real fast

 

[Henry Townsend]

Oh, I also wanted to say that if you are using Struts, then you are
(assuming you are writing your own) using some sort of container
(Tomcat, Jetty, Resin, Weblogic, Websphere etc). If this is the case
then you should probably use the pooling that is in the container
itself. You would then set up a "datasource" and use that within the
application. Let the application server handle pooling. You shouldn't
have to do this in your web-app.

This raises a point I've wondered about over the last couple of years
and it may be the right place to finally see what others think. In the
old days a webapp, if it needed DB pooling, used a standalone pool
package. The modern recommendation seems to be "let the container handle
it". But it seems to me the best thing about the servlet API is the
concept of the self-contained war file; stick it on any container and
it's good to go. However, no sooner was that model robust and ready than
the same designers broke it by putting pooling in the container. Now I
have to tweak server.xml (or the equivalent in non-Tomcat containers) to
install a webapp. Why is this better?

Put a little differently: if you're a classic web-based single-site
business like say Amazon, that's great because you own the server and
tweaking it is what you do. In that scenario the DB is likely shared by
a number of webapps. But if you're trying to ship a product packaged as
a war file with its own dedicated DB it's a giant step backwards, and
people with that situation might still prefer a pooling package such as
those mentioned. Right?

Henry Townsend

 

[eunever32]

That's a good point.

A work-around we have used it to put the xml snippet in

webapps/<App>.xml
where the app resides in
webapps/<App>/

This way it's possible to configure each app separately.

It would be preferable as you say to put the connection details in
webapps/<App>/WEB-INF/web.xml

 

[Harry Bosch]

Hmmm. Well, in your case it may be better to do it that way. But, I
would have to say that, unless you are embedding the db into the
application, the customer is still going to need to set up the database
connection paramaters, correct? The concept of the container was
always to manage resources for you. So, I have always recommended that
you use this (the j2ee) strategy. The concept of just copying a war
file and having it work is not what our j2ee overloard spec makers
intended. There was always a "deployer" role that configured the
application for deployment, whether it be at deployment time or
pre-deployment (meaning creating the appropriate descriptor files for
the target app server).

But, again, you can still always do it the way you are saying. You can
have your own connection pool.

The real problem by using your own connection pool is when you have
more than one application using the same database. Now you no longer
have a central area to configure connections and such for the shared
database. You now have maintain <i>n</i> number of pools for the same
resource. This can be a real hassle. What if you were given only 10
connection to a DB? how do you divide that between 3 applications?
So, that is just a hypothetical.

 

[Henry Townsend]

Hmmm. Well, in your case it may be better to do it that way. But, I
would have to say that, unless you are embedding the db into the
application, the customer is still going to need to set up the database
connection paramaters, correct?

True, though I did explicitly say I was addressing the case of an
application contained in a war file "with its own dedicated DB".

The concept of the container was

always to manage resources for you. So, I have always recommended that
you use this (the j2ee) strategy. The concept of just copying a war
file and having it work is not what our j2ee overloard spec makers
intended. There was always a "deployer" role that configured the
application for deployment, whether it be at deployment time or
pre-deployment (meaning creating the appropriate descriptor files for
the target app server).

Good point.

But, again, you can still always do it the way you are saying. You can
have your own connection pool.

Right, and this is the point I was trying to make. Not that
container-managed persistence and pooling are "wrong" per se. Just that
they're not necessarily "right" either, which your previous response
seemed to imply.

HT

 

[Bryce]

That's a good point.

A work-around we have used it to put the xml snippet in

webapps/<App>.xml
where the app resides in
webapps/<App>/

This way it's possible to configure each app separately.

It would be preferable as you say to put the connection details in
webapps/<App>/WEB-INF/web.xml

You can also put the context information in its own file in the war
itself under:

META-INF/context.xml

 

[Harry Bosch]

But that only works in Tomcat, am I correct?

 

[MileHighCelt]

Thank you for your help. Since I am using Struts/Tomcat I was
wondering if anyone had any examples of how to use this. I need to
have the XML define the datasource, and then do I use a DAtaService to
look it up and return Connections to clients, or maybe the DataService
takes the SQL and executes it?

I am looking at various patterns (Factory, Abstract) to do this because
I am concerned about resources and performance.

Thank you again for your help.