1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision: 1.2 $ -->
<chapter xml:id="oci8.connection" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink">
<title>Connecting Handling</title>
<para>
The oci8 extension provides you with 3 different functions for
connecting to Oracle. It is up to you to use the most appropriate
function for your application, and the information in this section is
intended to help you make an informed choice.
</para>
<para>
Connecting to an Oracle server is a reasonably expensive operation, in
terms of the time that it takes to complete. The <function>oci_pconnect</function>
function uses a persistent cache of connections that can be re-used
across different script requests. This means that you will typically
only incur the connection overhead once per php process (or apache child).
</para>
<para>
If your application connects to Oracle using a different set of
credentials for each web user, the persistent cache employed by
<function>oci_pconnect</function> will become less useful as the
number of concurrent users increases, to the point where it may
start to adversely affect the overall performance of your Oracle
server due to maintaining too many idle connections. If your
application is structured in this way, it is recommended that
you either tune your application using the <link
linkend="ini.oci8.max_persistent">oci8.max_persistent</link> and <link
linkend="ini.oci8.persistent_timeout">oci8.persistent_timeout</link>
configuration settings (these will give you control over the
persistent connection cache size and lifetime) or use
<function>oci_connect</function> instead.
</para>
<para>
Both <function>oci_connect</function> and <function>oci_pconnect</function>
employ a connection cache; if you make multiple calls to
<function>oci_connect</function>, using the same parameters, in a
given script, the second and subsequent calls return the existing
connection handle. The cache used by <function>oci_connect</function>
is cleaned up at the end of the script run, or when you explicitly close
the connection handle. <function>oci_pconnect</function> has similar
behaviour, although its cache is maintained separately and survives
between requests.
</para>
<para>
This caching feature is important to remember, because it gives the
appearance that the two handles are not transactionally isolated (they
are in fact the same connection handle, so there is no isolation of any
kind). If your application needs two separate, transactionally isolated
connections, you should use <function>oci_new_connect</function>.
</para>
<para>
<function>oci_new_connect</function> always creates a new connection to
the Oracle server, regardless of what other connections might already exist.
High traffic web applications should try to avoid using
<function>oci_new_connect</function>, especially in the busiest sections of
the application.
</para>
</chapter>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"../../../manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->
|
