Connection pooling verse one connection per session

[Mark Winslow <ma...@yahoo.com>]

Hi, I have a sort of theoretical question.  I'm
wondering about the pros and cons of using a "one
connection per tomcat session" strategy for connecting
to a Postgresql server rather than connection pooling.
 

My users generally login in the morning and keep my
app open for extended periods of time, usually
serveral hours at least.  The one connection per
session method seems to work well.  Here are the
reasons I'm using it.

1.  Can cache prepared statements, something that is
more problematic to do with a generic connection pool.

2.  Have better control of connection releases via the
finalize() method in a session "helper" class that
contains the one single connection.

3.  Easier to code and implement than connection
pooling.

4.  Potentially faster than connection pooling because
of only one connection open per session.  

Are there issues that I'm overlooking?  If I had more
users with shorter sessions, would it make a
difference?


Thanks.



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/ 

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org

Re: Connection pooling verse one connection per session

[QM <qm...@brandxdev.net>]

On Thu, Mar 10, 2005 at 10:31:41AM -0800, Mark Winslow wrote:
: Hi, I have a sort of theoretical question.  I'm
: wondering about the pros and cons of using a "one
: connection per tomcat session" strategy for connecting
: to a Postgresql server rather than connection pooling.

The great benefit of pooling is that objects that aren't being
(actively) used by one person/login/etc can be used by another.  
Put another way, the Connection objects aren't specific to a user, so
there's no need to treat them as such.  (If you've done any EJB, think
of Stateless vs Stateful Session Beans.)

You say your users are logged into your app all day; but are they
constantly streaming data from the minute they login to the minute they
logout?  If not, then holding open the DB connection for them isn't
helping much.  (I'd hesitate to say it's "doing harm" or anything "bad,"
just that it's not helping.)

For this same reason, pooling also helps in scalability: when a
Connection is idle (not being used by anyone), someone else can use it.  



: 1.  Can cache prepared statements, something that is
: more problematic to do with a generic connection pool.

True; but have you seen a significant performance gain due to prepared
statement caching?


: 2.  Have better control of connection releases via the
: finalize() method in a session "helper" class that
: contains the one single connection.

I'm not sure I understand this.  If your app is written such that
data-access code fetches a Connection as needed, then returns it to the
pool when it's done (Connection#close()), then what other control would
you need?

You realize, for a pooled connection, close() doesn't really shutdown
the network connection.  It just sends the Connection object back to the
pool.


: 3.  Easier to code and implement than connection
: pooling.

Again, I don't understand this.  Please explain.


: 4.  Potentially faster than connection pooling because
: of only one connection open per session.  

Yes and no. The connection pool keeps the connection open all the time;
so users who go through a pooled Connection object don't suffer any
"first time access" hits.

-QM


-- 

software  -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-user-help@jakarta.apache.org