Re[2]: DBCP status?

[Anton Tagunov <at...@mail.cnt.ru>]

Hello Serge!

Serge Knystautas wrote:
SK> I agree trying to recover connections is bad.  I've found it leads to 
SK> problems that don't show up during a test phase become very confusing 
SK> and challenging problems in production once under high-load.

SK> The approach I took was this....
SK> a) support an optional max-active time threshold, which means there is a 
SK> time limit to how long a connection can be marked as in use.
SK> b) if this threshold is exceeded, you close the connection.  The value 
SK> of trying to return it to the pool is minimal, while the downside of 
SK> returning a mid-transaction/statement connection to a pool is very bad 
SK> and nearly impossible to track down.

Yes, the connection shouldn't be put back to pool.

Yes, we should log this as an error.

Yes, the Throwable from section c) will greately help.

If the pool is to provide any feedback statistics
probably we should report separately three values:
* # of active connections
* # of idle connections
* # of over-timed connections

Now, two questions of the year:

 b1) to close this connection or not to close?
 
 b2) if maxActive > 0 should this connection no longer be counted
     as active for the purpose of enforcing the policies of
     WHEN_EXHAUSTED_FAIL
     WHEN_EXHAUSTED_BLOCK
     ?

I guess we have to choose from the following matrix of alternatives

b1  b2
1   1
0   0
0   1

Thoughts?

SK> c) support an optional debug step that will create a Throwable when 
SK> getConnection is called.  Then if the max-active threshold is hit, we 
SK> can print the stack trace of where the aged connection was grabbed, and 
SK> in development/testing, quickly resolve the errant connection.

This is a separate idea on its own and a very good one I think :-)
The message logging a connection that has been borrowed from the
pool too long will greatly benefit from this stack trace.

- Anton


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