Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
MIME-Version: 1.0
References: <55C69232.8070400@gmail.com>
 <CALznzY4o92EMxpNO1x_8RLwK41ozKbSQ9ux4CmQH-kGpOLAU9A@mail.gmail.com>
 <55C69BFF.1020207@gmail.com>
 <CALznzY7RwXBmbK_jyR8NZRu1tMmUaiWd3euUYEw4owS7S=kEJA@mail.gmail.com>
 <55C76CCC.1020409@oliver-heger.de> <55C77331.3090100@gmail.com>
 <CALznzY6CV67Q-anCsy=4KCef0Bh7eYgz_kxQ1m5S0tD87XOX8g@mail.gmail.com>
 <CALznzY6mG-u5f1PidkpQTktkMddgeOywD-QhpvXdwQTyHh75eg@mail.gmail.com>
In-Reply-To: 
 <CALznzY6mG-u5f1PidkpQTktkMddgeOywD-QhpvXdwQTyHh75eg@mail.gmail.com>
From: James Carman <james@carmanconsulting.com>
Date: Sun, 09 Aug 2015 17:17:17 +0000
Message-ID: 
 <CALznzY5XcsksYZi-k1a1=iFLNfRsvNb_3ZZeVPbMiF8b76yn7A@mail.gmail.com>
Subject: Re: [pool] Interceptors
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=047d7b47238017d4e7051ce40bfd

--047d7b47238017d4e7051ce40bfd
Content-Type: text/plain; charset=UTF-8

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.  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.

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.


On Sun, Aug 9, 2015 at 11:53 AM James Carman <james@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.
> On Sun, Aug 9, 2015 at 11:45 AM James Carman <james@carmanconsulting.com>
> wrote:
>
>> I lean toward listeners instead. Much simpler
>> On Sun, Aug 9, 2015 at 11:35 AM Phil Steitz <phil.steitz@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.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
>>>
>>>

--047d7b47238017d4e7051ce40bfd--