On Aug 9, 2015 12:17 PM, "James Carman" <ja...@carmanconsulting.com> wrote: > > Okay, how about this for a proposal? We create a new module in > commons-proxy called commons-proxy-pool which has a nice base class for > folks to be able to create proxy objects to be members of their pool. We > could call it ProxiedPoolableObjectFactory or something like that. This > class would have helper methods or whatever to make it easy to create proxy > objects which can include interceptors and what not. Then, commons-pool > doesn't have to know anything about proxies at all. It just continues to > manage a pool of objects of a certain type. The objects just happen to be > proxies that (may or may not) have interceptors. We don't have to worry > about synchronization either. >
+1 for dogfood and avoiding reinvention. Matt > As for the logging (and metrics, etc) solution, I still think a listener > pattern is the way to go. Furthermore, I would suggest we deliver the > "events" asynchronously to avoid slowing down the pool. The events would > be stuff like "object borrowed", "object returned", etc. > > > On Sun, Aug 9, 2015 at 11:53 AM James Carman <ja...@carmanconsulting.com> > wrote: > > > 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 > >>> > >>>
