像许多Java开发者一样，我经常看到关于有状态会话Bean所伴随的所谓可扩展性问题，我简单地接受了这些问题是真实的，并拒绝考虑使用有状态Bean。我想这可能是懒惰，但我们没有时间验证我们读到的每一件事 - 而且我从未有过理由怀疑我所读的是正确的。
几个月前，当我和Christian在泰国科诺凯恩的一家酒店房间里确定我们对“应用程序事务”的概念时，我强烈地意识到有状态的Bean是保持与应用程序事务相关联的状态的完美地方。（应用程序事务是从用户的角度看的一个工作单元；它跨越多个数据库/JTA事务。）例如，你可以为有状态Bean的整个生命周期保持一个专门的Hibernate会话，从而避免在每个请求时都需要分离和重新附加对象图。
这使得我开始思考人们谈论的可扩展性问题的原因。一旦我开始真正思考这个问题，它就根本无法解释！没有故障转移的有状态Bean与具有服务器亲和力的HttpSession相当，这是一个通常被认为可接受地扩展良好的设计。同样，有状态Bean的故障转移应该与HttpSession故障转移一样容易实现。
实际上，使用有状态Bean应该可以提高性能，因为我们不再需要在每个请求上都将与应用程序事务相关的状态序列化到Web层或数据库/之间/。将状态保持在中间层，与业务逻辑在一起，这似乎更加自然。
我当时得出的结论是，可扩展性问题一定是由现有应用服务器中的实现问题引起的。
那天我和一个在J2EE供应商工作的朋友谈论了这个话题，她把我指向这篇出色的论文
这篇论文真正驳斥了那个特定的迷信。
实际上，关于所谓的“无状态”架构的可行性，有很多胡言乱语的文章。确实，一个真正的有状态设计可能具有一些很好的可扩展性特性。问题在于，无状态应用实际上无法做任何有意义的事情。在现实应用中，状态/必须存在于某个地方/。将它序列化到和从网络层是纯粹浪费力气。将它序列化到数据库甚至更糟。
将来，我想我会一直使用有状态bean。
教训：警惕J2EE传说！
