Sophie: php-manual-en-4.3.0-2mdk noarch

php-manual-en-4.3.0-2mdk.noarch.rpm

<HTML
><HEAD
><TITLE
>Persistent Database Connections</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.7"><LINK
REL="HOME"
TITLE="PHP Manual"
HREF="index.html"><LINK
REL="UP"
TITLE="Features"
HREF="features.html"><LINK
REL="PREVIOUS"
TITLE="Connection handling"
HREF="features.connection-handling.html"><LINK
REL="NEXT"
TITLE="Safe Mode"
HREF="features.safe-mode.html"><META
HTTP-EQUIV="Content-type"
CONTENT="text/html; charset=ISO-8859-1"></HEAD
><BODY
CLASS="chapter"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>PHP Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="features.connection-handling.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="features.safe-mode.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="chapter"
><H1
><A
NAME="features.persistent-connections"
>Chapter 21. Persistent Database Connections</A
></H1
><P
>&#13;   Persistent connections are SQL links that do not close when the
   execution of your script ends. When a persistent connection is
   requested, PHP checks if there's already an identical persistent
   connection (that remained open from earlier) - and if it exists, it
   uses it. If it does not exist, it creates the link. An 'identical'
   connection is a connection that was opened to the same host, with
   the same username and the same password (where applicable).
  </P
><DIV
CLASS="note"
><BLOCKQUOTE
CLASS="note"
><P
><B
>Note: </B
>
    There are other extensions that provide persistent connections, such as
    the <A
HREF="ref.imap.html"
>IMAP extension</A
>.
   </P
></BLOCKQUOTE
></DIV
><P
>&#13;   People who aren't thoroughly familiar with the way web servers work
   and distribute the load may mistake persistent connects for what
   they're not. In particular, they do <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>not</I
></SPAN
> give
   you an ability to open 'user sessions' on the same SQL link, they
   do <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>not</I
></SPAN
> give you an ability to build up a
   transaction efficiently, and they don't do a whole lot of other
   things. In fact, to be extremely clear about the subject,
   persistent connections don't give you <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>any</I
></SPAN
>
   functionality that wasn't possible with their non-persistent
   brothers.
  </P
><P
>&#13;   Why?
  </P
><P
>&#13;   This has to do with the way web servers work. There are three ways
   in which your web server can utilize PHP to generate web pages.
  </P
><P
>&#13;   The first method is to use PHP as a CGI "wrapper". When run this
   way, an instance of the PHP interpreter is created and destroyed
   for every page request (for a PHP page) to your web server.
   Because it is destroyed after every request, any resources that it
   acquires (such as a link to an SQL database server) are closed when
   it is destroyed. In this case, you do not gain anything from trying
   to use persistent connections -- they simply don't persist.
  </P
><P
>&#13;   The second, and most popular, method is to run PHP as a module in a
   multiprocess web server, which currently only includes Apache. A
   multiprocess server typically has one process (the parent) which
   coordinates a set of processes (its children) who actually do the
   work of serving up web pages. When each request comes in from a
   client, it is handed off to one of the children that is not already
   serving another client. This means that when the same client makes
   a second request to the server, it may be serviced by a different
   child process than the first time. What a persistent connection
   does for you in this case it make it so each child process only
   needs to connect to your SQL server the first time that it serves a
   page that makes use of such a connection. When another page then
   requires a connection to the SQL server, it can reuse the
   connection that child established earlier.
  </P
><P
>&#13;   The last method is to use PHP as a plug-in for a multithreaded web
   server. Currently PHP 4 has support for ISAPI, WSAPI, and NSAPI (on
   Windows), which all allow PHP to be used as a plug-in on multithreaded
   servers like Netscape FastTrack (iPlanet), Microsoft's Internet Information
   Server (IIS), and O'Reilly's WebSite Pro. The behavior is essentially
   the same as for the multiprocess model described before. Note that
   SAPI support is not available in PHP 3.
  </P
><P
>&#13;   If persistent connections don't have any added functionality, what
   are they good for?
  </P
><P
>&#13;   The answer here is extremely simple -- efficiency. Persistent
   connections are good if the overhead to create a link to your SQL
   server is high. Whether or not this overhead is really high depends
   on many factors. Like, what kind of database it is, whether or not
   it sits on the same computer on which your web server sits, how
   loaded the machine the SQL server sits on is and so forth. The
   bottom line is that if that connection overhead is high, persistent
   connections help you considerably. They cause the child process to
   simply connect only once for its entire lifespan, instead of every
   time it processes a page that requires connecting to the SQL
   server. This means that for every child that opened a persistent
   connection will have its own open persistent connection to the
   server. For example, if you had 20 different child processes that
   ran a script that made a persistent connection to your SQL server,
   you'd have 20 different connections to the SQL server, one from
   each child.
  </P
><P
>&#13;   Note, however, that this can have some drawbacks if you are using a
   database with connection limits that are exceeded by persistent
   child connections. If your database has a limit of 16 simultaneous
   connections, and in the course of a busy server session, 17 child
   threads attempt to connect, one will not be able to. If there are
   bugs in your scripts which do not allow the connections to shut
   down (such as infinite loops), the database with only 16 connections
   may be rapidly swamped. Check your database documentation for
   information on handling abandoned or idle connections.
  </P
><DIV
CLASS="warning"
><P
></P
><TABLE
CLASS="warning"
BORDER="1"
WIDTH="100%"
><TR
><TD
ALIGN="CENTER"
><B
>Warning</B
></TD
></TR
><TR
><TD
ALIGN="LEFT"
><P
>&#13;    There are a couple of additional caveats to keep in mind when
    using persistent connections. One is that when using table
    locking on a persistent connection, if the script for whatever
    reason cannot release the lock, then subsequent scripts using the
    same connection will block indefinitely and may require that you
    either restart the httpd server or the database server. Another is
    that when using transactions, a transaction block will also carry
    over to the next script which uses that connection if script execution
    ends before the transaction block does. In either case, you can
    use <A
HREF="function.register-shutdown-function.html"
><B
CLASS="function"
>register_shutdown_function()</B
></A
> to register a
    simple cleanup function to unlock your tables or roll back your
    transactions. Better yet, avoid the problem entirely by not using
    persistent connections in scripts which use table locks or
    transactions (you can still use them elsewhere).
   </P
></TD
></TR
></TABLE
></DIV
><P
>&#13;   An important summary. Persistent connections were designed to have
   one-to-one mapping to regular connections. That means that you
   should <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>always</I
></SPAN
> be able to replace persistent
   connections with non-persistent connections, and it won't change
   the way your script behaves. It <SPAN
CLASS="emphasis"
><I
CLASS="emphasis"
>may</I
></SPAN
> (and
   probably will) change the efficiency of the script, but not its
   behavior!
  </P
><P
>&#13;   See also <A
HREF="function.fbsql-pconnect.html"
><B
CLASS="function"
>fbsql_pconnect()</B
></A
>,
   <A
HREF="function.ibase-pconnect.html"
><B
CLASS="function"
>ibase_pconnect()</B
></A
>, <A
HREF="function.ifx-pconnect.html"
><B
CLASS="function"
>ifx_pconnect()</B
></A
>,
   <B
CLASS="function"
>imap_popen()</B
>, <A
HREF="function.ingres-pconnect.html"
><B
CLASS="function"
>ingres_pconnect()</B
></A
>,
   <A
HREF="function.msql-pconnect.html"
><B
CLASS="function"
>msql_pconnect()</B
></A
>, <A
HREF="function.mssql-pconnect.html"
><B
CLASS="function"
>mssql_pconnect()</B
></A
>,
   <A
HREF="function.mysql-pconnect.html"
><B
CLASS="function"
>mysql_pconnect()</B
></A
>, <A
HREF="function.ociplogon.html"
><B
CLASS="function"
>OCIPLogon()</B
></A
>,
   <A
HREF="function.odbc-pconnect.html"
><B
CLASS="function"
>odbc_pconnect()</B
></A
>, <A
HREF="function.ora-plogon.html"
><B
CLASS="function"
>Ora_pLogon()</B
></A
>,
   <A
HREF="function.pfsockopen.html"
><B
CLASS="function"
>pfsockopen()</B
></A
>, <A
HREF="function.pg-pconnect.html"
><B
CLASS="function"
>pg_pconnect()</B
></A
>, and
   <A
HREF="function.sybase-pconnect.html"
><B
CLASS="function"
>sybase_pconnect()</B
></A
>.
  </P
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="features.connection-handling.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="features.safe-mode.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Connection handling</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="features.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>Safe Mode</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>