I lean toward listeners instead. Much simpler On Sun, Aug 9, 2015 at 11:35 AM Phil Steitz <phil.ste...@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.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 > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
