Yes, a JVM (Java Virtual Machine) can store stuff in memory, while PHP generally needs to store stuff in an external session (file or db). That also means that moving to more than one front end web server is a piece of cake (for PHP) – it's extra work in a java environment (either extra work for the server admin, or the code, or both).
I felt there was a lot of depth and meaning behind this statement, but i couldn't understand why. Then it hit me: one of the methods to achieving truly scalable architectures is the shared nothing approach. Shared nothing means that “neither memory nor peripheral storage is shared among processors”. This makes it highly scalable because no single server can be the bottleneck of the whole system. Then PHP's decision to disallow application variables and the like makes a lot of sense.
Given a fast connection to the Internet and a load balancer, you can create an server farm with hundreds of servers very easily in PHP by duplicating the source code on each machine and storing data and sessions in a database. The only bottleneck then is the database, where there are well-tested methods to enhance scalability (clustering, master-slave database servers, multiple db servers partitioned by function).
In contrast, J2EE encourages partitioning of applications into JSP's, servlets, and beans, which can be allocated to different servers. Although J2EE does not disallow shared nothing, it's very design encourages you to run different parts of a transaction on different machines; for example, a web server running JSP could require an EJB running on another server. This makes creating a server farm more challenging because of the inherent complexity of the technology. Failover also becomes more tricky because of the many entities involved. This is not to say that J2EE is not scalable, but in such a system the complexities increase as the number of parameters increase.
The Case for Shared Nothing – Michael Stonebraker (PDF)
J2EE Clustering – Abraham Kang