In Chapter 8 we discussed the development of session-based applications using the PHP session management features. In this appendix, we:
Discuss the motivation for storing session variables in the database tier of a web database application
Show how PHP session handlers are written to implement user-defined methods
Develop a fully functional set of PHP handlers that use a table in a MySQL database to store session variables
HTTP is a stateless protocol that allows applications to distribute resources across more that one web server. This allows an application to distribute requests across many web servers, thus dividing the load and permitting scaling of the application.
One of the main problems for session-based web applications is scalability. Implementing session management in the middle tier of an application forces all HTTP requests to be processed by a particular web server. To provide session support, all HTTP requests that belong to a session must be processed in the context of the session variables. Consider an application that holds the contents of a shopping cart using session variables. An HTTP request that submits an order must be processed by reading the session variables that hold the state of the cart. Figure D-1 shows the three-tier architecture of a web database application, with the session store in the web server environment. This is the approach described in Chapter 8.
Moving the session data to the database allows an application to scale horizontally at the middle tier as shown in Figure D-2. The web server doesn't have to keep session variables, so HTTP requests can be processed by different web servers. The PHP scripts on each web server still implement the application logic, but session variables are retrieved from a central database. In many applications, the middle tier—the layer that implements the application logic—is the performance bottleneck. By deploying multiple web servers, HTTP load balancing can be achieved and the database server better utilized. However, there is a point at which the performance of the DBMS becomes the bottleneck. Also, allowing multiple web servers to access a central database server requires strategies to control concurrent access, a topic discussed in Chapter 6.
Copyright © 2003 O'Reilly & Associates. All rights reserved.