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