Hi,
sorry for the late reply, but I've been very busy in the last weeks.
I still wanted to make some comments on the changes to the synchronization in
GenericObjectPool (and that like) - not sure which JIRA number refers to that.
I think one of the few good things about the strong synchronization in pool's
1.3 implementation was the fact that the creation of new objects was
serialised. This is gone with the patch, i.e. multiple objects may be created
in parallel. Let me explain why I think this is bad:
- creating a new object means the pool is exhausted which in turn usually means
that we have a high-load situation.
- creation of new objects is expensive (probably even more in high-load
situations). This is why we originally used the pool
- so in conclusion it is probably a bad idea to create multiple object in
parallel
My suggestion is to protect the creation of new objects with a different lock
to serialise it. E.g. (sketch):
// create new object when needed
if(null == pair) {
synchronized(makeObjectLock) {
Object obj = _factory.makeObject();
...
}
}
Usage of a different lock ensures that other operations on the pool don't block
because of object creation in progress.
Additionally you probably want to recheck if an object was returned to the pool
while you were waiting on the lock:
if(null == pair) {
synchronized(makeObjectLock) {
if( objectIsStillNotAvailable() ) {
Object obj = _factory.makeObject();
...
} else {
// return obj from pool
}
}
}
If you want to make the serialisation on the object creation configurable you
can even add a method to provide the lock:
synchronized( getMakeObjectLock() ) {
...
}
private Object getMakeObjectLock() {
if( this.serialObjectCreation ) {
return this.makeObjectLock;
} else {
return new Object();
}
}
greetings
Christoph
-------- Original-Nachricht --------
> Datum: Sun, 9 Dec 2007 20:35:28 -0700
> Von: "Phil Steitz" <[EMAIL PROTECTED]>
> An: "Jakarta Commons Developers List" <dev@commons.apache.org>
> Betreff: Re: [POOL] Offer of help for a 1.4 release
> On Dec 9, 2007 4:46 PM, Mark Thomas <[EMAIL PROTECTED]> wrote:
> > Mark Thomas wrote:
> > > Phil Steitz wrote:
> > >> On Dec 2, 2007 11:09 AM, Mark Thomas <[EMAIL PROTECTED]> wrote:
> > >>> Hi,
> > >>>
> > >>> Tomcat has been bitten [1] by a bug [2] in pool-1.3. Currently we
> are
> > >>> considering reverting to pool-1.2 but would obviously prefer to move
> to
> > >>> pool-1.4 (that included a fix for [2]) due to the many fixes in 1.3.
> > >>>
> > >>> A quick scan of the archives suggests that an offer of an extra pair
> of
> > >>> hands might help speed up a pool-1.4 release in the near term. So,
> here I am.
> > >> Thanks! This is exactly what is needed.
> > >
> > > OK. I have trunk checked out and building. I'll starting looking at
> > > POOL-86, POOL-97, POOL-93 & POOL-108 in terms of reviewing what is
> there
> > > and developing patches where there are gaps. I'll need to get my head
> > > around the pool code so I might be quiet for a couple of days.
> > >
> > > I'll add JIRA comments when I have something useful to say.
> >
> > I have taken a look at each of the issues above. Comments added to JIRA.
> In
> > summary:
>
> Thanks!
>
> > POOL-86 - The patch in JIRA looks good to me
> To be clear, are you referring to the patch that was applied in
> rr582538. - i.e., the code in trunk? (thanks, btw, for completing
> some cleanup missed there :)
>
> > POOL-93 - Proposed improved patch based on patches in JIRA
> Committed.
>
> > POOL-97 - Proposed alternative patch that fixes 97 without a regression
>
> Committed.
>
> > POOL-108 - Proposed improved patch (see POOL-93) based on patch in JIRA
> >
> > I'm happy to re-work any/all of the patches if required.
>
> Only rework required will be if we decide to roll back or modify the
> POOL-86 change.
>
> Thanks again for your help on this.
>
> Phil
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
