in reply to Re: Sharing database handle
in thread Sharing database handle

This is a nifty thought, but I'd worry that it would make the parent/server a bit monstrous and hard to get right. I guess if each child request is read, executed and answered back to the child in one block, it's certainly manageable.

There still is the empirical question: is it better to serialize all activity through a single, very active connection, as opposed to having a bunch of connections (leaving it to the DBMS to coordinate the actions, which is, in part, what it was written to do)? I don't really know that yet (sorry).

Replies are listed 'Best First'.
Re: Re: Re: Sharing database handle
by Zapawork (Scribe) on Apr 21, 2002 at 18:05 UTC
    Sorry about the late response,
    Proof to the pudding, so to speak, for this type of practive goes back to the ODBC models that all of your modern day websties use.
    Having one central connection allows you to control access while guaranting preformance. If you need data in a large scale form, you usually implement application servers to cache and give performance enhancements.
    Hope this helps
    Dave -- Saving the world one node at a time
[reply]

In Section Seekers of Perl Wisdom