If you want to decorate the calls to the pooled objects, then use commons proxy and a delegator proxy. Let's not bleed into other areas. Let pool concentrate on what it does best. On Sun, Aug 9, 2015 at 11:45 AM James Carman <ja...@carmanconsulting.com> wrote:
> 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 >> >>
