1 |
dpavlin |
237 |
considerations on the design of a PHP interface |
2 |
|
|
|
3 |
|
|
This paper is based on the requirements of |
4 |
|
|
> Concurrency |
5 |
|
|
|
6 |
|
|
|
7 |
|
|
* why not to export sessions |
8 |
|
|
|
9 |
|
|
From the C-API's point of view, the use of sessions is a MUST |
10 |
|
|
in a multithreaded environment, which PHP may be. |
11 |
|
|
This, however, is the server-side of the PHP engine. |
12 |
|
|
The PHP page, as seen by the programmer, is a client to the database: |
13 |
|
|
it does NOT handle multiple requests, but one! |
14 |
|
|
|
15 |
|
|
In other words, the page is already executing within the context of |
16 |
|
|
a given request, including a given thread. |
17 |
|
|
Since a request is not meant to operate on several sessions, |
18 |
|
|
but rather has one session as an attribute of it's context, |
19 |
|
|
nothing would be gained by making the session visible ("export") |
20 |
|
|
to the PHP programmer by calls like read(ses,...) or ses->read(...). |
21 |
|
|
|
22 |
|
|
|
23 |
|
|
Moreover, the currently most used environments, i.e. MP Apache 1.x/Unix |
24 |
|
|
and some Windoze boxes, do not allow/require the use of multiple sessions, |
25 |
|
|
anyway. |
26 |
|
|
|
27 |
|
|
Finally, the only reason to explicitly select a session based on a user's |
28 |
|
|
session id, would be to access this session's state as #1-style result sets |
29 |
|
|
or authentication information. Both will not be implemented in the near |
30 |
|
|
future and both will rarely be needed in web environments. |
31 |
|
|
Yet, it might be made available when needed by means of an additional |
32 |
|
|
call that "selects" that session as the one to be associated with the |
33 |
|
|
request context. |
34 |
|
|
|
35 |
|
|
|
36 |
|
|
* strategy |
37 |
|
|
|
38 |
|
|
Therefore, I would suggest the following strategy: |
39 |
|
|
- In the first step, stick to the default session by using a static |
40 |
|
|
session variable like openisis_ses0 and auto-initializing it like |
41 |
|
|
the OPENISIS_SES0 macro does. |
42 |
|
|
- For the MP version register a function using register_shutdown_function |
43 |
|
|
(is there a corresponding C-API to register a C function ?) |
44 |
|
|
that closes all open DBs in order to release their flocks. |
45 |
|
|
(Berlin will provide such a "close all"). |
46 |
|
|
- On Windoze and Apache 2, make sure to actually run single-threaded |
47 |
|
|
by using EnterCriticalSection/pthread_mutex_lock |
48 |
|
|
on a static CRITICAL_SECTION/PTHREAD_MUTEX_INITIALIZER |
49 |
|
|
and leaving/unlocking it in a registered shutdown_function |
50 |
|
|
- Some day, in a better age, replace the static session variable |
51 |
|
|
with a thread specific one by using pthread_key_create/pthread_setspecific |
52 |
|
|
or maybe PHP's TSRM. |
53 |
|
|
|
54 |
|
|
C.f. man pthread_mutex_lock, |
55 |
|
|
> http://msdn.microsoft.com/library/en-us/dllproc/base/critical_section_objects.asp critical Windoze |
56 |
|
|
|
57 |
|
|
|
58 |
|
|
* notes |
59 |
|
|
|
60 |
|
|
- is there a call in the PHP API that can be relied upon |
61 |
|
|
to be the first one used, in order to do initialization? |
62 |
|
|
Probably opening a DB? |
63 |
|
|
- In the MT version, closing databases is not enforced, |
64 |
|
|
thus successive requests will open already opened databases. |
65 |
|
|
This is ok with the C-API's DOpen, which will happily return |
66 |
|
|
the same handle. |
67 |
|
|
- Once additional worker sessions/threads are supported, |
68 |
|
|
we'll need additional open/close calls, which do neither |
69 |
|
|
actually open or close a database, but access and release |
70 |
|
|
(and possibly flush). The MT and MP usage could then be made |
71 |
|
|
to look very similarm with details governed by a few config |
72 |
|
|
settings. |
73 |
|
|
|
74 |
|
|
--- |
75 |
|
|
$Id: PHP.txt,v 1.1 2003/02/13 20:36:23 kripke Exp $ |