commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [pool] Interceptors
Date Sun, 09 Aug 2015 15:35:13 GMT
On 8/9/15 8:07 AM, Oliver Heger wrote:
>
>
> 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".

Thanks, Oliver and very good point on synchronization.  This would
require care.  The nice thing about pool2 is that we have vastly
reduced the scope of synchronization.  Most importantly (actually
since about pool 1.5), factory methods are all outside of sync
blocks and no locks are held on objects checked out by the pool
[1].  That said, we would need to be careful not to create liveness
or performance issues and we would have to provide good
documentation on things to look out for when implementing interceptors.

Phil

[1] The pool maintenance thread and borrow / return operations do
acquire locks on the PooledObject wrappers used by the pool, but not
on the objects that the interceptors would be working with. 
Thread-safety of pool methods should ensure that use of pool
references in interceptors would also be safe.


>
> My 2 cents
> Oliver
>
>>
>> On Sat, Aug 8, 2015 at 8:18 PM Phil Steitz
>> <phil.steitz@gmail.com> 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 <phil.steitz@gmail.com>
>>> 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: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>>
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>



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


Mime
View raw message