Why set a JSP page session = "false" directive?

One reason would be performance and memory. If you have a page that doesn't need to be involved in a session (like say, an about.jsp or faq.jsp) then the default behaviour of involving every JSP in a session will impose the overhead of creating a new session object (if one doesn't already exist) and increased memory usage as more objects reside on the heap.

This effect will be greatly exaggerated in case of a single page seeing high traffic from many unique users combined with a high bounce rate i.e. they users do not continue to browse but leave the site immediately after viewing that one page- the container will create a new session object per user which will never be used again and will ultimately be garbage collected after it times out - added over head of object creation, memory usage and garbage collection without giving you any real value.

This setting is also a security measure, as it also avoids a potential DoS attack. Think about a simple script that iteratively wgets the JSP: it will generate a lot of sessions in few seconds.

I actually have a real scenario in my app for its usage. We have Squid acting as a reverse proxy in front of our application. The squid server is set up to poll all the tomcat instances hosting our application to verify that the servers are up and running, if they are not, Squid will fail over to using another server in our cluster.

The actual polling to our app from Squid is set to poll a specific page in the app. Since Squid's poll is not actually a browser, it can't hold a session, which means that each poll to the server page would have tomcat create a session which Squid cannot hold a reference to. We add the <%@ page session="false" %> directive so that a session is not created on each poll. If we did not use this directive, we would have thousands of sessions created over 4 hours time for no reason.

Yet another use case where it is actually required to add this directive is when using Apache Shiro's noSessionCreation filter in the .ini configuration file, e.g. because your authentication scheme is stateless. If you lack it, you'll run into a org.apache.shiro.subject.support.DisabledSessionException.

Ran into another use case in my production application, figured I'd share it here in case it helps somebody.

We have a Web UI app that protects most resources via session. However, some resources are protected by part of the web tier that sits in front of our app in our production deployment. Therefore, as far as the app is concerned, these resources are totally unprotected. Some of these "unprotected" resources are JSPs.

In the case where a user establishes a session on one of our protected resources, then makes an XHR call from the browser to one of the "unprotected" resources, we were hitting an issue where the container claims that an anonymous user is trying to access a session of user foo, thus stopping execution. Configuring the "unprotected" JSP to not use sessions got us around this problem.