commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [pool] Interceptors
Date Sun, 09 Aug 2015 15:45:46 GMT
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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message