commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Heger <>
Subject Re: [pool] Interceptors
Date Sun, 09 Aug 2015 15:07:56 GMT

On 09.08.2015 02:49, James Carman wrote:
> Yep, same thing I said back in the day. Would we want it to be a true
> "interceptor" or more of a "listener"?

Sounds like a usual and interesting feature. IIUC the proposal of Phil, 
it goes more in the direction of interceptors.

A point to keep in mind is how does this feature impact synchronization? 
Can interceptors be invoked outside of synchronized blocks? Otherwise, 
there is a certain risk of introducing subtle bugs. Bloch calls this 
"calling an alien method with a lock held".

My 2 cents

> On Sat, Aug 8, 2015 at 8:18 PM Phil Steitz <> wrote:
>> On 8/8/15 5:04 PM, James Carman wrote:
>>> We talked about this a while back with respect to logging,, having a
>>> PoolListener interface or something.
>> Right.  That could be one use.  The nice thing there is the
>> interceptor could bring in whatever logging / event propagation
>> infrastructure it wanted to use.
>> Phil
>>> On Sat, Aug 8, 2015 at 7:36 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.
>>>> Phil
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message