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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
