On Jan 5, 2008 7:49 AM, <[EMAIL PROTECTED]> wrote: > Hi Phil, > > thanks for taking my issue serious. > > Phil Steitz wrote: > > > Thanks again for the feedback. Any other opinions / suggestions on > > this are appreciated. I suggest the following compromise, which would > > also fix the maxActive exceeded by one issue I discovered with > > 1.2/1.4-RC1 yesterday: > > > > (*) Move makeObject back inside synchronized scope in borrowObject. > > (patch below) > > > > This addresses Christoph's production use case (assuming I have > > understood it correctly) and also closes the maxActive exceeded by one > > problem that my testing uncovered yesterday. It does not have a huge > > performance impact in the tests that I have run and still leaves > > activation and validation (the per-request operations) outside of > > synchronized scope. More elegant solutions to both problems are > > certainly possible and we can consider them in subsequent releases - > > including configurable serialization of just the makes. > > This is not what I was trying to achieve :-( > While this fixes my issue with the parallel creation of objects, it > reopens another issue which I have with the implementation in pool 1.3: > > The pool blocks completely while an object creation is in progress. > Just consider the following use case: > > - Thread A tries to borrow an object. The pool contains no idle objects, > hence a new one is created > - While object is still in creation, Thread B tries to return his > borrowed object to the pool. Since returning the object depends on the > same synchronization lock as makeObject, B will block as long as the new > object isn't created (which can maybe take several seconds, as seen in > my use case). I think this is unacceptable.
Agreed. This is why the synchronization was removed. Bad idea to stay with the 1.3 setup. > - Still while the creation is in progress, Thread C wants to borrow an > object. It cannot continue, either, though an idle object would be > available, if B could have returned its object > > I propose, as in my previous post, a distinct lock for object creation. > I have attached a patch which should fix this behavior, but probably > will not fix the "maxActive exceeded by 1". Do you already have a > testcase for this one? I am working on this now. I don't have a unit test yet. I discovered the problem using load tests generated using the performance module in commons-sandbox. The dummy factory that the pool tests use keeps track of (makes - destroys) and throws IllegalStateException if this quantity exceeds maxActive for the pool. I was able to get this to happen using the config I posted on the other thread. >The existing unit tests run without errors when > my patch is applied. > Thanks! Testing now. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]