On Tue, 02 Oct 2001 07:08:47 -0700, Aaron Bannert wrote: > On Tue, Oct 02, 2001 at 02:30:26AM -0700, Greg Stein wrote: >> On Mon, Oct 01, 2001 at 11:54:44PM -0700, Justin Erenkrantz wrote:
>> > > * Connection Pooling per server (ie we keep a max of n open >> > > connections >> > > to a server and we re-use these on different requests) >> > >> > Eh, I'm not terribly sure about this though. I'm not sure how you >> > would get the lifetimes right. Ideally, the connections should >> > timeout themselves. I guess we could enforce the lifetimes with >> > socket timeouts (but that'd only be on our side not the server side). >> > I think that if you want connection-pooling, that *might* be outside >> > of the scope of this library. But, I'm not really sure. Thoughts? >> >> All of this would be subject to various parameters and controls, TBD. >> >> I generally agree that it is an advanced concept and possibly able to >> relegate to the app, but I also think that many apps will want multiple >> connections and multiple outstanding requests. Thus, a pool of >> connections. > > Something to be built upon our base library. true, the pool would allow you to perform low-latency requests to a application server, by creating the connection and re-using it over and over, instead of creating/tearing-down the connection for every request. The lifetime of a connection would handled by the server in this case, as keep-alives are currently done. you could program the pool so that it has multiple servers it talks to for load balancing, where a client may issue multiple 'gets' to the same 'pool' and they may be served from multiple machines/ports, invisible to the calling program ..Ian > > [snip] > > -aaron
