Women in Technology

Put simply PHP is stateless - unless you store it externally (such as the server side of a PHP Session cookie) it's lost come the next request between requests. Very few PHP applications do more than store user session data between requests.

The longer explaination is when you make a request to a PHP script, Apache passes the request to the PHP engine to handle, which in turn first parses the PHP script (this stage can be reduced script caching such as Zend Accelerator) then executes it, re-building any data, objects etc. for that request.

The concern that this inherent stateless is bad news comes from a fundamental lack on understanding of how to take advantage of it.

For example if you choose to implement a Front Controller in PHP in a Struts-like fashion, parsing a giant XML file _ON EVERY REQUEST_, you've got it wrong. A large part of design PHP applications is to focus on page controllers which restrict themselves only to creating the objects / data they need, _not_ loading every concievable class / object for all your Page Controllers. Arguably, Apache is PHP's Front Controller.

Done right, PHP actually scales better exactly _because_ of it's inherent statelessness - there's no concerns relating to how to replicate runtime data across seperate machines. All you need to do is replicate the a mimimal user session store (which hopefully you didn't put in your database!) and as the article points out, pass persistent data form a form using the form itself.

The bottom line - what would you rather do? Use the replication at a network, filesystem and database level to achieve scalability (where it's fast, easy to maintain and supported by mature technologies) or would you rather do it at an application level (i.e. application server level) where you're relying on immature technologies that are re-inventing wheels which already exist (usually with significant overhead e.g. application level messaging protocols) and have an extra layer of complexity to worry about.