tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Reynir Hubener" <rey...@hugsmidjan.is>
Subject RE: JDBC Connection Pool Theory ??
Date Mon, 24 Sep 2001 16:11:30 GMT
The most expensive part of working with databases is instanciating
connections.
so really it makes alot of difference to have those instanciated from
the beginning.
The reasons for using connection pooling mechanism are many... I cant
remember a single reason why someone should not use one.  Just the fact
that it simplifies the access to the database from your servlets is big
enough reason.
It´s very simple to install and use.

the one I recomend is free software from www.bitmechanic.com

hope it helps, 

reynir hubner
reynir@hugsmidjan.is
cto 








-----Original Message-----
From: Jonathan Eric Miller [mailto:jemiller@uchicago.edu]
Sent: 24. september 2001 15:55
To: tomcat-user@jakarta.apache.org
Subject: Re: JDBC Connection Pool Theory ??


What I want to know is how much of a difference connection pooling
really
makes? My application isn't taking a lot of hits, so, maybe if it was, I
would notice the difference, but, right now, I see no need to use
connection
pooling.

Jon

----- Original Message -----
From: "Gustavo Saramago" <wesak@ig.com.br>
To: <tomcat-user@jakarta.apache.org>
Sent: Friday, September 21, 2001 6:23 AM
Subject: Re: JDBC Connection Pool Theory ??


> It's hard to imagine a real world application without database access.
The
> JDBC spec delegate the responsability for connection pool
implementation
to
> th JDBC driver vendor. This result in proprietary implementations of
pools
> that reduce code portability.
>
> General solutions like Poolman are good choices. It's a light piece of
code
> as Jon said, but I have saw people having problems using it with
Tomcat.
Our
> lives would be mutch easier if the JDBC spec had defined a standard
> connection pool.
>
> Why Tomcat do not implement a connection pool? Nothing aganist
Poolman,
but
> standards are welcome.
>
> ----- Original Message -----
> From: "Jon Shoberg" <jshoberg@cbd.net>
> To: <tomcat-user@jakarta.apache.org>
> Sent: Friday, September 21, 2001 12:48 AM
> Subject: RE: JDBC Connection Pool Theory ??
>
>
> >
> >
> > One of the issues would be someting that has been crossing the lists
> > recently.  Few people have posted that poolman is broken under
TC4.0.
> I'll
> > have to try it myself and see. However, I like to do my own plumbing
:)
> >
> > Jon
> >
> > -----Original Message-----
> > From: Vladimir Grishchenko [mailto:vladgri@hotmail.com]
> > Sent: Thursday, September 20, 2001 10:32 PM
> > To: tomcat-user@jakarta.apache.org
> > Subject: Re: JDBC Connection Pool Theory ??
> >
> >
> > "Professional Java server programming " from WROX had a chapter
about
it,
> as
> > far as I remember. I can't call it a "comprehensive study", but it
had
> some
> > meaningful explanations.
> >
> > What's wrong with poolman btw? IMHO it is as simple as it gets, your
> > application doesn't even know it deals with pooled connections.
Portable?
> As
> > portable as Java itself.
> >
> >  My philosophy on such things is take it if it's available and
concentrate
> > on your application domain issues and not the plumbing (plumbing in
good
> > sense here...).
> >
> > --V.
> >
> >
> > ----- Original Message -----
> > From: "Jon Shoberg" <jshoberg@cbd.net>
> > To: <tomcat-user@jakarta.apache.org>
> > Sent: Thursday, September 20, 2001 7:37 PM
> > Subject: JDBC Connection Pool Theory ??
> >
> >
> > >
> > > Can anyone suggest or point to readings on JDBC connection pool
theory?
> > > Something that covers how a pool is implemented, best case / worst
case
> > > scenarios, tips and traps.
> > >
> > > My next web application is looking to be very database (mysql)
> intensive.
> > > I would like a pooling mechanism that is VERY simple to use, VERY
light,
> > low
> > > overhead, and portable.  Having looked at packages such as
poolman, I
> > > decided I need to learn a bit more about JDBC and pooling in
general.
> Any
> > > thoughts ?
> > >
> > > Jon
> > >
> > >
> >
>


Mime
View raw message