Can we please not top-post.  Gets hard to follow.

On 8/9/15 10:17 AM, James Carman wrote:
> Okay, how about this for a proposal?  We create a new module in
> commons-proxy called commons-proxy-pool which has a nice base class for
> folks to be able to create proxy objects to be members of their pool.  We
> could call it ProxiedPoolableObjectFactory or something like that.
Have you looked at the ProxiedObjectPool already in [pool].  It
pretty much does what we need.

>   This
> class would have helper methods or whatever to make it easy to create proxy
> objects which can include interceptors and what not.  Then, commons-pool
> doesn't have to know anything about proxies at all.  It just continues to
> manage a pool of objects of a certain type.  The objects just happen to be
> proxies that (may or may not) have interceptors.  We don't have to worry
> about synchronization either.

I think there is value in having a configurable interceptor
construct integrated with the pool, having access to the pool as
well as the pooled object.  Have a look at tomcat's jdbc-pool for
some examples.  That pool *is* a proxy object pool (they don't use
delegatingXxx constructs like jdbc does).  For [pool] (and [dbcp]) I
would like to keep the proxying configurable (so no registered
interceptors means no proxies). 
>
> As for the logging (and metrics, etc) solution, I still think a listener
> pattern is the way to go. Furthermore, I would suggest we deliver the
> "events" asynchronously to avoid slowing down the pool.  The events would
> be stuff like "object borrowed", "object returned", etc.

Agreed, some of that is already in place.  Some interceptors may
gather stats, though, as part of their function.
>
>
> On Sun, Aug 9, 2015 at 11:53 AM James Carman <ja...@carmanconsulting.com>
> wrote:
>
>> If you want to decorate the calls to the pooled objects, then use commons
>> proxy and a delegator proxy. Let's not bleed into other areas. Let pool
>> concentrate on what it does best.

Right now, the proxying in ProxiedObjectPool is done by a pluggable
proxy source.  Currently, a jdk proxy source is provided and a
source based on cglib.  If you think that the setup there could be
improved somehow using Commons Proxy, we can certainly look at it.

Phil


>> On Sun, Aug 9, 2015 at 11:45 AM James Carman <ja...@carmanconsulting.com>
>> wrote:
>>
>>> I lean toward listeners instead. Much simpler
>>> On Sun, Aug 9, 2015 at 11:35 AM Phil Steitz <phil.ste...@gmail.com>
>>> wrote:
>>>
>>>> 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.ste...@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.ste...@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-unsubscr...@commons.apache.org
>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>>>



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

Reply via email to