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>
In-Reply-To: <55C77331.3090100@gmail.com>
From: James Carman <james@carmanconsulting.com>
Date: Sun, 09 Aug 2015 15:45:46 +0000
Message-ID: 
 <CALznzY6CV67Q-anCsy=4KCef0Bh7eYgz_kxQ1m5S0tD87XOX8g@mail.gmail.com>
Subject: Re: [pool] Interceptors
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=001a113d5874c30971051ce2c33e

--001a113d5874c30971051ce2c33e
Content-Type: text/plain; charset=UTF-8

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

--001a113d5874c30971051ce2c33e--