Note the timewarp here... I'm catching up on random threads I find
On Mon, 2 Dec 2002, Michael Engelhart wrote:
> Of course you could set Webware to keep 100 instances around but then
> you're limited to "guessing" what your client request rate would be
> which is almost guaranteed to be wrong in a public web site. Note
> that I'm currently building a site that probably won't need more than
> the default instance pool that Webware provides but I'm trying to come
> up with a programming methodology for building Webware applications
> that makes sense to me and will avoid me having to switch between two
> very different programming models.
I think this is definitely a case where the instance pooling algorithm is
getting in the way of the threading vs. non-threading philosophy
discussion. What I mean is, the fact that the pool is currently a static
number of instances -should- be regarded as an implementation detail
subject to change, and that change should be to introduce a dynamic
pooling algorithm. This is true of DBPool and, well, every pooling
So, in case it wasn't clear, the pool should increase its size to
accomodate instantaneous demand and then trim itself back down to a
reasonable size when the demand subsides.
It's actually easier to implement this than it sounds... When a request
comes in for a pool object, the pool looks for an existing instance. If
there are no existing instances, it doesn't -immediately- create one.
Rather, it waits a specified time for an existing instance to become
available, and, if not, -then- creates a new one. This puts an upper bound
on the time a client will have to wait for a handler. This timeout is
pretty easy to implement using a lock.wait(timeout) call on a lock that
represents instance availability in the pool's internal queue.
Discarding extra pool instances is left as an exercise to the reader :)
> > There are many conveniences to coding with non-threadsafe servlets, and
> > it makes factoring significantly easier. Pooling works well, and is
> > Webware's alternative to threadsafeness (but only for servlets --
> > everything else still has to be threadsafe or pooled on its own, as
> > with DBPool).
I have to second Ian's analysis of the conveniences here :)
I've been meaning to write a generic pooling mechanism that implements the
strategy described above, and could be used to pool just about anything,
but, uh, I haven't :)