>>> Allow persistent connections to be closed and 'pruned'. I'm unclear as to the reason for this one. Unless people are using lots of different username/password combos in which case the connections should not be persistent. Persistent connections were made to make speed up repetitive identical connections as is often found in web applications (and where end user security is often then handled by the app, not the database). [PHP Manual: Chapter 22: ...In particular, they do not give you an ability to open 'user sessions' on the same SQL link...]
However, I'd like to add a item to the list proposed by Zac and Monty: Persistent connection pools that are _per server_ rather than _per process_. Perhaps it would be activated if the mm module were included. It amazes me that this difference is still not explained in the manual. The only reference is the configuration of php.ini. Things like mysql.max_persistent are also _per process_ (duly noted in that part of the manual), but have a completely different meaning than might be usually expected. For example, mysql.max_persistent effectively has to do with the max number of different server/user/pass combinations of persistent connections that that process makes. For a web app connecting to only one MySQL server with the same user/pass, this parameter is meaningless. This, of course, is important only to Apache servers where you must multiply the per process items above by the max number of child servers Apache will run. Sincerely, Steven Roussey http://Network54.com/?pp=e -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
