commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christoph Kutzinski" <ku...@gmx.de>
Subject Re: [POOL] Offer of help for a 1.4 release
Date Thu, 03 Jan 2008 09:20:57 GMT
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" <phil.steitz@gmail.com>
> 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 <markt@apache.org> wrote:
> > Mark Thomas wrote:
> > > Phil Steitz wrote:
> > >> On Dec 2, 2007 11:09 AM, Mark Thomas <markt@apache.org> 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: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message