> As for database drivers, I think it's never acceptable for a driver to > fatal because of a failed connection -- there's already a well-established > mechanism to report and detect connection failures at the time of a "ns_db > gethandle", and if that fails, you can exit yourself; if you want to make > sure you can connect to the DB at startup, do a gethandle and exit if it > fails; no reason to have the module issue the fatal, especially because > there may be cleanup required before the process terminates.
What is the point of having the DB module load, if it can't connect to the DB server? In fact, this was a problem for us, where the server would start, the DB module would load, but later it wouldn't be able to make connections because the DB server was down. So we had to hack something up in our TCL startup routines to actually *DO* a database operation during the AS boot to make sure the database was accessible. And the retry code in the DB mechanism is not exactly robust: if there is a pooled connection to the DB server and the connection dies, AS gives back weird errors to ns_db gethandle until the pool is bounced, which doesn't happen automatically. The other thing to keep in mind is that if a particular server fails hard, then load-balancers etc. handle that much better than when a server returns "Sorry, we could not get a DB handle for your request". If the server is actually down, the load balancer will likely take it out of the pool. If the server is returning errors, it will probably stay in the pool. JMHO.
