On 11/2/10 10:05 AM, Steven Siebert wrote:
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?
I think the config classes either need to be mutable (as they are
now in trunk for GOP) so the individual properties remain
*individually* mutable or - my preference - they are immutable and
used only by the ctors and they are not used to proxy changes to the
pool properties.
One consideration with this is mutability of JMX, each individual change
though this interface would call reconfigure().
-1 for forcing that.
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 =)
+1 for MBean exposing properties. See my last post on what
properties should be mutable.
Phil
S
On Tue, Nov 2, 2010 at 3:33 AM, Simone Tripodi<simone.trip...@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.ste...@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-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
