On 10/17/10 8:53 AM, Benoit Perroud wrote:
Making pool be able to be resized at runtime will introduce extra
complexity, that could be otherwise totally delegated to a BlockingQueue as
backend structure.
I don't understand exactly what you are saying here. The question
is should the user-exposed properties governing the size, max number
of idle elements, etc. be mutable at runtime. Regardless of the
choice of data structure to maintain the pool, deciding this in the
negative puts some serious constraints on user code.
Moreover is there some ideas of what kind of implementation will be used to
implement the pool v2 ?
Current thinking is to integrate the code from the Tomcat jdbc-pool
module.
ArrayBlockingQueue is IMO a good candidate, and it even has a "fair"
behavior that jdbc-pool try to reimplement on its own.
We should talk about why the Tomcat devs decided to implement their
own FairBlockingQueue.
As a side note, as of 1.5, the now "legacy" [pool] code implements
fairness. The Tomcat code is configurable - i.e., can behave fairly
or not. I have just started analyzing the performance tests
included in jdbc-pool, but they appear to indicate that, as
expected, fairness dampens mean response but decreases variance. I
like the approach of making fairness configurable.
Phil
Kind regards,
Benoit.
2010/10/13 Simone Tripodi<simone.trip...@gmail.com>
Hi guys,
I'd add that not all properties are configurable, we should add
setters only in case it makes sense, or not?
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Wed, Oct 13, 2010 at 2:19 AM, Phil Steitz<phil.ste...@gmail.com>
wrote:
On Oct 12, 2010, at 4:42 PM, Jörg Schaible<joerg.schai...@gmx.de>
wrote:
Gary Gregory wrote:
I too would like to be able to tweak the size of the pool at runtime.
Gary
On Oct 12, 2010, at 13:19, "James Carman"<ja...@carmanconsulting.com>
wrote:
On Tue, Oct 12, 2010 at 11:22 AM, Simone Tripodi
<simone.trip...@gmail.com> wrote:
Hi Phil! :)
honestly I didn't understand which are the use cases when a pool
needs
to be reconfigured, that's why I've always used the pool in
"configure
and use" modality and Seb's suggestion sounded good to me. OTOH I
didn't modify any single code line before hearing your thoughts since
you know much more than me.
If pool's property are mutable, so I need to add the setters, make
them final otherwise :P
What if you want to alter the way the pool works at runtime? Perhaps
you're seeing that it keeps causing long waits because you're not
allowing it to grow big enough?
Why then not create a new pool and take over ownership of the objects?
There may be instances out in circulation. Also requests waiting,
maintenance in progress, etc not to mention the need to redirect clients.
The flexibility to be able to increase pool size or change other parameters
on the fly is good IMO and where we can safely support it without
performance impact we should.
- Jörg
---------------------------------------------------------------------
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
