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). | [reply] |
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] |