我知道，通常出于可扩展性的原因，我们不喜欢在服务器上维护会话状态，但我不明白为什么Play 2.0所采用的方法据说比老式的HttpSession更好。
我看到的一个主要区别是，HttpSession实现是由容器提供的，因此HttpSession的扩展能力取决于容器
这有很多优点。从本质上讲，Play中的会话模型促进了一种无共享的架构。这意味着，如果您遵循Play所提倡的模式，执行的每个操作都是RESTful请求，则该操作的执行完全是自包含的。这意味着每个请求都可以单独进行单元测试，并将应用程序构建为一组离散函数。
这里的原则是，每个动作之间的耦合越小，胖会话处理的会话状态越少，代码就越干净、越健壮。
作为副作用，您还可以通过水平添加更多节点来轻松进行扩展，这通常比垂直扩展便宜，也比粘性会话复杂和风险更小。
使用容器管理的会话（及其封装的状态）意味着，当您想要水平扩展时，相关系统还必须确保复制此状态，因为没有它，您的应用程序将无法工作。使用您应用程序的客户端有效地绑定到用户碰巧指向的特定节点。
相比之下；当您的应用程序在任何时候都没有保持真正的会话状态时（正如您的Play应用程序应该保持的那样），很容易横向扩展：只需添加更多运行应用程序的节点，并确保前端HTTP服务器知道新节点。没有花哨的算法和"企业平台"可以在所有节点上复制和维护会话。
不，它实际上比这复杂一点。Play实际上推动了无状态应用程序体系结构。也就是说，您没有在会话中存储任何数据。除了可以存储凭据之外，什么都不存储。
第一条规则：会话存储被驱逐到数据库。与其从会话中获取数据，不如从数据库中获取数据。与JVM应用程序相比，数据库的可扩展性要容易得多。
第二条规则：除凭据外，不存储任何内容。也就是说，你必须以其他方式传递信息才能进入对话状态。有两种主要的方法可以做到这一点。使用隐藏字段，在我看来这不是最好的方法。其次使用绝对URL。创建一个包含id、搜索和其他内容的URL。