+++ /dev/null
-considerations on the design of a PHP interface
-
-This paper is based on the requirements of
-> Concurrency
-
-
-* why not to export sessions
-
-From the C-API's point of view, the use of sessions is a MUST
-in a multithreaded environment, which PHP may be.
-This, however, is the server-side of the PHP engine.
-The PHP page, as seen by the programmer, is a client to the database:
-it does NOT handle multiple requests, but one!
-
-In other words, the page is already executing within the context of
-a given request, including a given thread.
-Since a request is not meant to operate on several sessions,
-but rather has one session as an attribute of it's context,
-nothing would be gained by making the session visible ("export")
-to the PHP programmer by calls like read(ses,...) or ses->read(...).
-
-
-Moreover, the currently most used environments, i.e. MP Apache 1.x/Unix
-and some Windoze boxes, do not allow/require the use of multiple sessions,
-anyway.
-
-Finally, the only reason to explicitly select a session based on a user's
-session id, would be to access this session's state as #1-style result sets
-or authentication information. Both will not be implemented in the near
-future and both will rarely be needed in web environments.
-Yet, it might be made available when needed by means of an additional
-call that "selects" that session as the one to be associated with the
-request context.
-
-
-* strategy
-
-Therefore, I would suggest the following strategy:
-- In the first step, stick to the default session by using a static
- session variable like openisis_ses0 and auto-initializing it like
- the OPENISIS_SES0 macro does.
-- For the MP version register a function using register_shutdown_function
- (is there a corresponding C-API to register a C function ?)
- that closes all open DBs in order to release their flocks.
- (Berlin will provide such a "close all").
-- On Windoze and Apache 2, make sure to actually run single-threaded
- by using EnterCriticalSection/pthread_mutex_lock
- on a static CRITICAL_SECTION/PTHREAD_MUTEX_INITIALIZER
- and leaving/unlocking it in a registered shutdown_function
-- Some day, in a better age, replace the static session variable
- with a thread specific one by using pthread_key_create/pthread_setspecific
- or maybe PHP's TSRM.
-
-C.f. man pthread_mutex_lock,
-> http://msdn.microsoft.com/library/en-us/dllproc/base/critical_section_objects.asp critical Windoze
-
-
-* notes
-
-- is there a call in the PHP API that can be relied upon
- to be the first one used, in order to do initialization?
- Probably opening a DB?
-- In the MT version, closing databases is not enforced,
- thus successive requests will open already opened databases.
- This is ok with the C-API's DOpen, which will happily return
- the same handle.
-- Once additional worker sessions/threads are supported,
- we'll need additional open/close calls, which do neither
- actually open or close a database, but access and release
- (and possibly flush). The MT and MP usage could then be made
- to look very similarm with details governed by a few config
- settings.
-
----
- $Id: PHP.txt,v 1.1 2003/02/13 20:36:23 kripke Exp $
projects / webpac / blobdiff