On Wednesday 16 May 2007, Andrew McIntyre wrote: > You can install the "classic" version of > firebird on Multi CPU machines and as long as you use database pooling > its fine (As slow to startup a connection because it starts a new process)
Yes, but in a practice situation you *know* how many simultaneous connections you are going to need, so what you do is start all necessary processes at boot time (process pooling). Then there won't be an delay at connection time. A good OS will nicely distribute processes across available resources (processors), and you have the huge advantage that no process can take any other process down or even slow it down if it crashes or something goes wrong (at least not on POSIX machines) - whereas threaded implementations (the common solution on Windows) a single thread going wrong/crashing/hanging will bring the whole application down (= all clients suffer if a single one had a problem) It also means that if there is a problem, a single process can be restarted, instead of the whole server = no productivity loss, the show goes on. Compared to these huge benefits (stability, independence of processes, crashproofness of system, automatic distribution across processors / resources) the necessary increase in resource use (memory) is negligible. The only situation where threaded database processes make sense is when you cannot predict how many simultaneous clients will connect, especially when connection times are rather short (eg online shopping application). For surgeries, implementation as separate processes will ALWAYS be more advantageous than implementation as threads - does MSSQL even offer the choice? Horst _______________________________________________ Gpcg_talk mailing list [email protected] http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
