On Friday 01 February 2002 12:28, Steve Willer wrote: > On Fri, 2002-02-01 at 10:36, Tod Harter wrote: > > I can tell you exactly why things need to be ordered that way. It might > > not seem right on the surface of it, but the problem is that its > > expensive with some protocols to establish the initial connection, so you > > don't want to be doing that for each method call, you need a SCOPE in > > which the connection is valid and a handle is held, so there needs to be > > a setup block of code BEFORE any calls are made and then a tear down > > afterwards. In our case we have SOAP doing object activation/deactivation > > and remote garbage collection, so once the handle to an object goes out > > of local scope remote garbage collection is triggered (via DESTROY). > > Database handles are an analogous situation. I expect that the ESQL > > taglib needs to construct them in the STARTING part of its tag sets, not > > later on (though one could devise ways to defer things). > > Yeah, that's probably a big part of why I don't like ESQL. All of those > explicit connections and stuff. > > I'm a big believer in using lazy initialization in these kinds of cases. > If I were to do this kind of thing, I would keep a cache of open > connections. When someone wants to connect to server X, I do a lookup > for a connection for server X. If it's not in the cache, I initiate one > and stick it in the cache. > > Then it's just a matter of deciding when to do the cleanup. The main > possibilities are to use a post-request cleanup handler, to not clean up > post-request, but instead do a quick run through the cache when someone > asks for a connection and get rid of "old" connections, or to do no > cleanup and let the connections die when the Apache child dies. > > I use the garbage-collecting approach for url->file lookup cache entries > (the "Sitemap", an internal module). For most database servers, I let > Apache kill the connections at die time, but for one of them (Sybase) > under certain circumstances I close the connection post-request. > > The advantage of this approach isn't just architectural. It's also in > the interfaces. If you do this lazy-connection stuff, you don't need to > have explicit "connect to server X now please" commands in your XML. > Just reference it, and the necessary connections are automatically > built.
I don't in general disagree with you. As I said in another post I generally use "prepare_cached" in DBI, which gets you a pretty good reuse rate on handles. Given the way Apache's process model works you seem to end up with about 1 db handle per child. It is possible to share handles across children with MySQL client lib it appears, so its pretty forgiving as to how you set things up. I know Sybase at least USED to be one database that was a lot pickier about how you used its handles. Oracle has some issues with that as well. As for lazy initialization with my SOAP contexts, it would hardly matter. Since HTTP is connectionless its not a big issue to share them between processes, but its really object lifetime management that I concern myself with here. I just don't want my service to be sitting around with instantiated objects that nobody is using just because a perl module got compiled. As for being lazy between the definition of the endpoint and the first method call, its 6 of one and half a dozen of the other. We did eventually work out doing it with TaglibHelper where the first method call does the actual instantiation/activation. All the outer enclosing tagset has to then is passivation, but deferring that to the end of the XSP page is OK as well USUALLY, but there are cases like if you want to activate and call a LOT of instances where you need to be able to push them out of scope and have them explicitly passivate before the page processing ends. All this is still a bit up in the air for us. One of these days when this whole project has been ironed out completely I'll do a paper on it. Our basic concept is using XSP as just a thin layer over a SOAP backend, so really all the major processing steps happen back there, XSP just makes the calls and converts the results to a palatable form of XML for styling. With proper failover the whole thing should be a pretty highly scalable "brick wall". --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
