Why should I use SQL Relay with Zope?
The same efficiency arguments that can be made against Apache::DBI and PHP’s persistent connections cannot be made against Zope. Zope maintains a hackable (some say “configurable”) number of persistent database connections in its cache and shares them among its threads. The number of database connections and threads are independent. There is always the possibility that one or all of the database connections will get pushed out of the cache and have to be started back up later, but in practice, this is highly unlikely and happens very infrequently. If you have such a large farm of Zope machines that the number of persistent database connections is straining the database server’s resources, SQL Relay can provide a middle tier to reduce the number of persistent connections. SQL Relay adds immediate support for load distribution over a group of clustered or replicated databases to Zope. SQL Relay can provide a means for connecting to databases for which there is no Zope adapter. When using
Related Questions
- Why doesn the last connection die off when I set connections=0 and maxconnections to some larger number and let SQL Relay go idle for a long time?
- If I set up SQL Relay to use dynamic scaling, it eventually spawns off as many connections as it can and they never die off. Whats up with that?
- Why should I use SQL Relay with Zope?