Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / October 2005

Tip: Looking for answers? Try searching our database.

open source jdbc pooling

Thread view: 
MileHighCelt - 03 Oct 2005 17:51 GMT
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 - 03 Oct 2005 18:40 GMT
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 - 03 Oct 2005 18:47 GMT
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.
Henry Townsend - 05 Oct 2005 16:08 GMT
> 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
[quoted text clipped - 3 lines]
> 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@yahoo.co.uk - 06 Oct 2005 10:45 GMT
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
Bryce - 06 Oct 2005 16:34 GMT
>That's a good point.
>
[quoted text clipped - 8 lines]
>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

--
now with more cowbell
Harry Bosch - 06 Oct 2005 17:38 GMT
But that only works in Tomcat, am I correct?
Harry Bosch - 06 Oct 2005 16:21 GMT
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 - 06 Oct 2005 16:31 GMT
> 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
[quoted text clipped - 3 lines]
> 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
Harry Bosch - 03 Oct 2005 19:03 GMT
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.
MileHighCelt - 12 Oct 2005 16:13 GMT
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.
jonck - 03 Oct 2005 21:25 GMT
> 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 - 05 Oct 2005 15:19 GMT
> 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
[quoted text clipped - 6 lines]
>
> 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 :)


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.