On 3/6/06, William A. Rowe, Jr. <[EMAIL PROTECTED]> wrote: > Jim Jagielski wrote: > > I think the whole issue revolves around whether the balancer > > should, or should not, pre-open connections and manage them > > internally, or whether it should be one-shot. The real > > power is being able to load balance, and implement > > that in a central location. > > > > So it seems to me that some sort of Balancer member > > option that determines whether or not the connection > > is "persistent" or not would alleviate some of > > the issues you raise. > > That would be the ideal model for any remoted ASP.NET container as well. > Some persistance flag to indicate that a backed should be persistant, > and pooled, and the pool constraints (for this client side, not the actual > backend's true constraints), would be ideal.
See, the issue for fastcgi isn't controlling persistence, persistent connections are fine as long as you're actually making use of the backend process, the problem is avoiding having more than one connection to a backend process that simply cannot handle multiple concurrent connections. This seems to be a problem unique (so far anyway) to fastcgi. -garrett
