We have one servlet (our controller servlet) which we have tagged in our web.xml as load on start up first. This servlet initializes the connection pool. Our class which wraps the connection pool is a Singleton class which has a public static member method to access the connection broker. This way all servlets and classes within the context share a single copy of the connection broker.
As documented, the minimum number of connections is established when the broker is initialized. The number of connections grows as needed. You will notice a parameter "double maxConnTime". This is a portion of a 24 hour day. That is 1.0 = 24 hours, 2.0 = 48 hours, .5 = 12 hours, .25 = 6 hours etc. Every this number hours the connections are closed and the minimum number of connections are re-established. This helps cut down on unused open connections and replaces any connections which have been dropped for whatever reason. This is may not be the most efficient way of managing connections, but it doesn't use much overhead either. Over all we have been quite happy with DDConnectionBroker. It seems quite reliable (sometimes simple is better) and the price is right! It also works fine with the Oracle driver, MySQL driver and freetds (for MS SQL). Jim > -----Original Message----- > From: Eddie Bush [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 06, 2002 9:25 AM > To: Tomcat Users List > Subject: Re: Who uses connection pool? > > > Jim, I couldn't tell from the page - with you having some experience with > the DDConnectionBroker, I thought I'd shoot you a couple of questions: > > Pool Instantiation > Do I need to create this pool in an initialization servlet and put an > instance of it in the servlet context? It looks like it's possible that > using this 'pool' might result in a new pool for each servlet... > which isn't > really going to solve any problems for me. In practice, how have you > noticed it to act? > > Connection Maintenance > The site has this to say: > > In the future, the number of connections in the pool will vary from > minConnections to maxConnections; minConnections will be available during > slow times; maxConnections will be in the pool when busy. (This is not > currently implemented.) > > What behavior have you observed? Does it just keep the increased > number of > connections? That doesn't sound very good either. > > Thanks so much! > > Eddie > > ----- Original Message ----- > From: "Jim Urban" <[EMAIL PROTECTED]> > To: "Tomcat Users List" <[EMAIL PROTECTED]> > Sent: Tuesday, March 05, 2002 3:31 PM > Subject: RE: Who uses connection pool? > > > > We use DBConnectionBroker regardless of the database. This way the its > > easier to switch databases depending on which one a client chooses. > > > > Jim > > > > > -----Original Message----- > > > From: Rich Sneiderman [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, March 05, 2002 1:27 PM > > > To: Tomcat Users List > > > Subject: RE: Who uses connection pool? > > > > > > > > > Hi folks, > > > > > > Ok, I know we've beaten this to death today but all this discussion > > > about DB Pooling got me thinking... > > > > > > Currently I'm using the Oracle thin client JDBC driver > (class12.jar) to > > > talk to a 9i database. I'm currently using the connection > > > pooling/caching support Oracle supplies (the OracleConnectionCacheImpl > > > class). Have any of you used this? How would you contrast it to say > > > poolman, Bitmechanic's pool code, or DBConnectionBroker (I > think that's > > > all the ones that have been thrown around today)? Would one > of these be > > > a better choice? Based on today's discussion I won't even consider > > > Tomcat's native pooling (tyrex). > > > > > > I'm still in development with my code and haven't put it under load so > > > it would be nice to know if this is a good route to take before we get > > > into production. > > > > > > Thanks in advance. > > > > > > - Rich > > > > > > -- > > > To unsubscribe: <mailto:[EMAIL PROTECTED]> > > > For additional commands: <mailto:[EMAIL PROTECTED]> > > > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > -- > > To unsubscribe: <mailto:[EMAIL PROTECTED]> > > For additional commands: <mailto:[EMAIL PROTECTED]> > > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > > > > -- > To unsubscribe: <mailto:[EMAIL PROTECTED]> > For additional commands: <mailto:[EMAIL PROTECTED]> > Troubles with the list: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
