A permanent database connection refers to a connection that does not close when your script ends. When a permanent connection is received. PHP will check if there is an existing permanent connection as (previously opened). If there is, this connection will be used directly; if it does not exist, a new connection is created. The so-called "same" connection refers to the connection with the same username and password to the same host.
The work and distribution of the Web server does not fully understand readers may incorrectly understand the permanent connection. Special, permanent connections will not provide you with the ability to build "user sessions" on the same connection, nor does it provide the ability to effectively establish a transaction. In fact, from strict sense, permanent connections will not provide you with any non-permanent connection that cannot be provided.
why?
This is related to the WEB server work. Your web server can use PHP to generate a web page with a three way.
The first method is to use PHP as a "housing". Operating in this way, PHP will request to generate and end a PHP interpreter thread for each PHP page proposed to your web server. Since the thread ends with the end of each request, any resource utilized in this thread (eg, a connection to the SQL database server) will close with the end of the thread. In this case, you will not change any way you use a permanent connection - because they are not permanent.
Second, it is also the most common method, which is a module that uses PHP as a multi-process web server. This method is currently only available for Apache. For a multi-process server, the typical feature is a parent process and a set of sub-process coordinated operation, which actually generates a web page is a subsystem. Whenever the client requests a request to the parent process, the request is passed to the sub-process that is not occupied by other clients. This means that when the same client files a request to the server, it will be able to be processed by a different sub-process. After opening a permanent connection, all subsequent pages that request SQL services can reuse this already established SQL Server connection.
The last method is to use PHP as a plugin for multi-threaded web servers. At present, PHP 4 has supported ISAPI, WSAPI, and NSAPI (in Windows Environments), which makes PHP can be used as a multi-threaded web server such as Netscape FastTrack (IPlanet), Microsoft's Internet Information Server (IIS), and O'Reilly's Website Pro. Plugin. The permanent connection behavior and the multi-process model described above are essentially the same. Note that PHP 3 does not support SAPI.
If there is no additional feature permanently connected, then we use it?
The answer is very simple - efficiency. The permanent connection will be more efficient when the client is very frequently requested by the connection request for your SQL server. The standards that the connection request is frequent depending on many factors. For example, if the type of database, database service and web services are on the same server, how the SQL server loads the load. But we know at least that when the connection request is very frequent, the permanent connection will significantly improve efficiency. It makes each sub-process only one connection operation in its lifecycle, rather than a connection request to the SQL server each time you process a page. This means that each sub-process will establish separate permanent connections to the server. For example, if you have 20 different subcompachments to run a script to establish a permanent SQL server permanently connected, then you have established 20 different permanent connections to the SQL server, each process holds one.
Note that if the number of subcompachments permanently connected exceeds the number of database connections you set, there will be some defects. If your database is limited to 16, with 17 threads attempt to connect, there is a thread that will not be connected. If this time, an error (such as an infinite loop) that cannot be closed in your script, the 16 connections of the database will be affected quickly. Check out the documentation of the database you use to get how to handle abandoned and idle connections. WARNING There are still some special issues to pay attention to using permanent connection. For example, when using a data table lock in a permanent connection, if the script does not release the data table lock, the script that will then use the same connection will be permanently blocked so that you need to restart the HTTPD service or database service. In addition, when the transaction is used, if the script ends before the transaction block generation is generated, the blocking will also affect the next script using the same connection. No matter what circumstances, you can use the register_shutdown_function () function to register a simple cleaning function to open the data table lock, or roll back the transaction. Or better processing methods, is not used in the script that uses a data table lock or transaction processing, which can fundamentally solve this problem (of course you can use permanent connection elsewhere).
The following is a little important summary. The permanent connection is designed to establish a one-to-one distribution for the usual connection. This means that you must ensure that your actions of your script will not change when you replace the permanent connection to a non-permanent connection. Use a permanent connection will (very) may change your script efficiency, but do not change its behavior!
