On Thu, Mar 10, 2005 at 12:30:22PM -0800, Mark Winslow wrote:
:
http://jakarta.apache.org/tomcat/tomcat-5.5-doc/printer/jndi-datasource-examples-howto.html#Database%20Connection%20Pool%20(DBCP)%20Configurations
:
: "There is one problem with connection pooling. A web
: application has to explicetely close ResultSet's,
: Statement's, and Connection's."
I'd hardly say that's a "problem"; that's just good coding practice. =)
(example: When I'm done cooking, I should turn off the stove. Is that a
problem with stoves, or just how stoves work?)
Connection cleanup maintenance is straightforward: liberally sprinlke
finally{} blocks around data access code. -and if that's abstracted out
into a layer, and a separate set of objects, you shouldn't have to look
in that many places to insert said finally{} blocks.
: For instance can you assume that the
: overhead to create a Pooled Connection based an an
: already established connection is negligable?
A pooled connection usually *is* an established connection. The idea of
pooling (any sort of object pooling) is that the app (here, Tomcat)
instantiates some number of said objects ahead of time, such that
they're ready to use when needed. In some cases the objects are created
on-demand but then kept around for future use.
Pooled Connection objects are wrapped in another object (that also
implements Connection) that intercepts close() calls. Instead of
actually closing the connection, it returns the object to the pool.
: There are threading
: issues involved with connection pools.
Such as...? As long as you treat a Connection as a hot potato -- hold
on to it only as long as you need, then pitch it -- there should be no
such threading issues. -and as long as you only fetch Connection objects
from the DataSource, then you should never run into an issue where two
sections of code get the same Connection.
: It's sort of a non-standard thing to
: do and maybe not worth any potential cpu/memory
: benefits. I think I'm probably trying to talk myself
: into droping my strategy and implementing connection
: pools.
For me, it's mostly a design issue. I design my apps such that I can
switch the connection source (pooled, one-off, etc) and the code is none
the wiser. It just knows, "I get a Connection here, and I call close()
on it when I'm done." Whether close() really terminates a network
connection/DB session, or just returns an object to the pool, it doesn't
matter...
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
