[EMAIL PROTECTED] wrote: > > The problem is that we're indeed trying not to waste database resources > because the db is used by many applications (java, c++, perl etc). So we'd > like to reserve only as many connections as really needed, possibly with > couple extra connections "just in case"
The pool will get new connections on an as needed basis up to some maximum amount. Since you need some connections available outside the pool, you would set the number used by the pool to a fraction of those available from the db. The pool does not have a dynamic resizing of the maximum number of connections. > > > If the connection pool is full and no apps are using the pool, I believe > > you are correct that the connections will be wasted. Are you wanting to > > free up connections to be used with other applications that are not > > getting connections from the pool? If so, the pool design will not work > > for you. > > The only quick fix I can think of is to have additional thread/servlet in > our application which would run permanently, periodically request > number of unused connections via DBConnection.getPool().getNbrAvailable() > and when this number exceeds some threshold, it would call > TurbineDB.getConnection/releaseConnection appropriate number of times to > get rid of expired connections. I think you will need to set a fairly short expiration time for a scheme like this to work. The pool design assumes a connection will get used many times within its lifetime. > > > If you are getting all connections throught the pool, I do not > > see why it matters how many connections are in the pool waiting to be > > used. Are you trying to minimize overall resource usage? > > yes that's the point and one of the reasons we're adding db connection > pooling to the application > > > I usually set the expiration at around 1 day, but you can probably set > > it higher, how long do you want them to live? > > I'd rather had this thing flexible so that a connection would live as long > as it's needed plus some extra configurable "expiration" time. That way > the connection wouldn't be closed just because it's too old even if some > code is ready to use it. It will not be closed while it is being used. That is why it is checked for expiration when it is returned. It is supposed to be closed if returned and the expiration time is exceeded. That way a potentially stale connection is not handed out to the next bit of code that is ready to use it. Why would you not want to close a connection that is expired? You do not want to give a stale connection out to some code that needs a connection, give the code a fresh one. I do not understand this. john mcnally --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
