Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of smsiebe@gmail.com designates
 209.85.214.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=UJsFQSQqjyVbPx6XcOcSPBwlNjAg5I/qvP0QFfill4t7h6pYH9/a9UgBhVqEfMPI9o
         4N5bionMElBDM7+fMEmnFPBOMETTQP/foE+fnQYAoNUF5sFvqwb11C7PdmaKBQZ8RrfK
         uo8ODAB3hEaP21yNwh20WcFkKkSbvsVOmILgg=
MIME-Version: 1.0
In-Reply-To: <AANLkTikgvibvoQg0cwWvT5UhdpOg1t1E-ZcJKQ2EyAw4@mail.gmail.com>
References: 
 <02AA127CD8DCDE48BC7D2DFB6C87083A07DB70FB@nwt-s-mbx2.rocketsoftware.com>
 <AANLkTinFyZsoQUbAhsvhh2aLbjGTMMOh5VPq5D0c30cd@mail.gmail.com>
 <AANLkTi=UogafFmoYwybe_TnJ1aYcF-u9yJSE9+SuTwt+@mail.gmail.com>
 <AANLkTinO91C1jbWYpogoD1RuumERO60CyGZNYAfpzO0n@mail.gmail.com>
 <AANLkTim25S3GkAYCzxabPnkHa6pg4DzHuNY2HBkw1Yzw@mail.gmail.com>
 <AANLkTikE9ETQ7KatZpc00dBV6GsSuSqkZP4p4-=3Q4sn@mail.gmail.com>
 <AANLkTiku6G0d7NMYAe7H-3+AH7MYEn0ZJqBZ-Ffgw8q+@mail.gmail.com>
 <AANLkTimxMEZ6heqYfNm=qqKyodqU2bfaM4ioaw27VVeE@mail.gmail.com>
 <AANLkTim-5O64QPJXuUuEcACba_A6hZFMy0wyafrXKXBv@mail.gmail.com>
 <4CCC4E23.4080109@gmail.com>
 <AANLkTikoQr+8NBOGurWEBaC8N8RbAxF2S11CafA6gAFY@mail.gmail.com>
 <4CCCC7C1.1030802@gmail.com>
 <02AA127CD8DCDE48BC7D2DFB6C87083A07DC38FB@nwt-s-mbx2.rocketsoftware.com>
 <4CCCE89B.3040200@gmail.com>
 <47827C26-0F66-445B-9FB4-3E84DF41CF84@seagullsoftware.com>
 <4CCE19A0.3050609@gmail.com> <4CCE1C4F.6050509@apache.org>
 <4CCE20F8.6090604@gmail.com>
 <AANLkTikgvibvoQg0cwWvT5UhdpOg1t1E-ZcJKQ2EyAw4@mail.gmail.com>
From: Steven Siebert <smsiebe@gmail.com>
Date: Tue, 2 Nov 2010 10:05:34 -0400
Message-ID: <AANLkTikxzQ34Mc7dUagAGQtzjb_Xu13kM1DekaMFyiXG@mail.gmail.com>
Subject: Re: [pool] Pool config vs. factory hierarchies.
To: Commons Developers List <dev@commons.apache.org>
Content-Type: multipart/alternative; boundary=20cf305641e15c4a2b0494126c2a

--20cf305641e15c4a2b0494126c2a
Content-Type: text/plain; charset=ISO-8859-1

Hey all,

Sorry I've been away from the discussion, I was stuck in a building with no
windows for the last week (quite literally) and had very little time to
breath.  At ApacheCon now, so have a bit of time to hack.

I caught up on the messages, and I agree with Gary as well.  What can I do
to help at this point?  I think the group decided to implement immutable
configuration classes...the pools would provide a reference in the
pools/factories and sync/reconfigure with the reconfigure()?  Is this right?
 One consideration with this is mutability of JMX, each individual change
though this interface would call reconfigure().  Now, I don't think there
would be frequent, sweeping, changes...so this probably won't be a huge
issue.  If we're going this route, JMX is a non-issue with this (just
confirming this).  Each pool would implement a MBean that would "expose" the
configuration settings as well as the pool-specific values (numWaiting, etc)
for read-only.  If this is good with the group, I look forward to
helping/completing this so I can finalize a patch for the JMX =)

S

On Tue, Nov 2, 2010 at 3:33 AM, Simone Tripodi <simone.tripodi@gmail.com>wrote:

> Hi all, Phil,
> thanks for the explanations, very appreciated, I join Gary on saying
> that maybe my thoughts on Pool are based on incorrect assumptions.
> Assembling thought from various email and this thread IMHO starts
> being a little difficult, If we could resume all that thoughts in a
> wiki page I can take care on refactoring the code to see the design in
> action.
> WDYT?
> Have a nice day,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Nov 1, 2010 at 3:07 AM, Phil Steitz <phil.steitz@gmail.com> wrote:
> > On 10/31/10 9:47 PM, Mark Thomas wrote:
> >>
> >> On 31/10/2010 21:36, Phil Steitz wrote:
> >>>
> >>> A radical idea that I have been considering is to propose that we
> >>> dispense with keyed pools altogether.  The DBCP need can be met without
> >>> them (see jdbc-pool)
> >>
> >> Can it? I know there are some things that DBCP can do that jdbc-pool
> >> can't such as https://issues.apache.org/bugzilla/show_bug.cgi?id=49543
> >>
> >> I thought keyed pools were required for that but I haven't given it much
> >> more than about 10s thought so I could be wrong.
> >
> > For SharedPoolDataSource the way it is currently implemented, yes; but
> > similar to the statement cache, that class does not use anywhere near the
> > full features of GKOP. It does not allow you to provide a pre-configure
> GKOP
> > or support cross-pool maintenance. The only thing it really needs is
> > maxTotal enforcement and a map of GOPs.  I guess having GKOP means you
> could
> > make SPDS more full-featured, but I wonder if its not overkill.
> >
> > Probably best to keep it around if we can find a simple performant way to
> > maintain it.
> >
> > Phil
> >
> >
> >>
> >> Mark
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

--20cf305641e15c4a2b0494126c2a--