On Thu, 23 Jan 2003, Stephen Westbom wrote: > The best way to handle it is to make the pool an active object (it should have > its own thread that comes alive every X milliseconds and does something). This > something for a connection pool would be to have a configuration option for > idle time on the poolable objects.
When configured to test idle connections, dbcp will spawn an independent thread for that evictor. In the CVS head of DBCP, there is also a publically avaiable evict() method that will invoke the eviction routine (and which could be driven by some external thread if the test-on-idle evictor isn't sufficient). > This is the standard way of doing things on the database, router tables etc. > The pool should mimic this behavior to avoid using excess sockets, database > connections etc. > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
