On 8/8/15 4:35 PM, Phil Steitz wrote: > Tomcat's jdbc-pool has an interceptor feature that allows custom > code to be inserted into methods called on connections managed by > the pool. In [pool], we have the core infrastructure to support > this in a generic way via the ProxiedObjectPool. I propose that we > extend this to allow users to configure interceptors to be called > when registered methods are invoked on checked out objects. I > haven't really thought through how configuration would work, but > basically clients would register methods and possibly interceptor > properties and the interceptors would get references to the method, > arguments, pool and pooled object. Configuring interceptors in a > GOP or GKOP would cause it to be wrapped in a ProxiedObjectPool. > Eventually, we could use this [pool] capability to enable the kind > of thing that jdbc-pool provides with its interceptors in DBCP. > With [pool] itself, I could see providing method stats collectors, > abandoned timer reset (avoiding having to implement use()) and maybe > a pooled object properties cache. If there are no objections, I > will open a JIRA and start experimenting.
Something concrete to talk about is attached to POOL-301. The example is something I could have used in an app I don't support any more - an interceptor that invalidates an object that responds too slowly. I would have needed something more sophisticated, but I think the basic setup of getting the method, args and the pool to the interceptor would have worked for me. The setup in the patch is primitive - just before/after interceptors and no invocation-level context (other than the method name, args, pooled object and pool). I am happy to close my own issue as WONT_FIX if others don't think this is a good idea. On the other hand, if people think it is a good idea and anyone wants to improve the patch, I would be happy to collaborate on this. One thing I should fairly note is that careful analysis of the interceptors provided with tomcat's jdbc-pool shows that only the slow query reporter provides functionality not already present in DBCP. The other interceptors all do things that DBCP can be configured to do without adding interceptors. Phil > > Phil > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
