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