Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Message-ID: <55C69BFF.1020207@gmail.com>
Date: Sat, 08 Aug 2015 17:17:03 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [pool] Interceptors
References: <55C69232.8070400@gmail.com>
 <CALznzY4o92EMxpNO1x_8RLwK41ozKbSQ9ux4CmQH-kGpOLAU9A@mail.gmail.com>
In-Reply-To: 
 <CALznzY4o92EMxpNO1x_8RLwK41ozKbSQ9ux4CmQH-kGpOLAU9A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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