将无状态会话bean转换为POJO的可伸缩性含义

Question

想象一下，一个使用频繁的服务对象是作为EJB 2.1 SLSB实现的，并且由于没有任何状态，它本身也恰好是线程安全的。它的所有公共方法都是事务性的（通过CMT），最简单的是需要一个事务，但有些需要新事务。

如果我将此SLSB转换为真正的单例POJO（例如使用DI框架），那将如何影响应用程序的可伸缩性？当服务是SLSB时，EJB容器将管理一个实例池，每个客户端将从中获取自己的副本，因此我想知道将它转换为单例POJO是否会为该单个实例引入某种争用。 / p>

FWIW，这项服务的方法都不是synchronized。

澄清：我将SLSB转换为POJO的动机是对象的生命周期（真正的单例与容器管理）和代码本身（一个接口和一个带注释的POJO，而不是三个接口，一个bean类，和ejb-jar.xml中的一堆XML。

此外，FWIW，有问题的服务是在JBoss 3.x上运行的并置Web应用程序的一个组件。

Answer 1

如果POJO是真正无状态的，或者没有会话状态（即状态是不可变的）那么这不会使性能恶化，甚至可能略有改善，因为你真的只使用DI框架中的一个实例而不是池从容器。 （即使是在高负荷下也会遭遇争用。）

设计中线程安全的对象不需要同步，例如没有或只是不可变状态的对象。没有争用 - 线程可以在没有同步的情况下自由地在POJO上执行方法。

通过使用POJO，您还可以看到您的应用程序中发生了什么，并且可以确定幕后没有隐藏的“容器魔法”。

Answer 2

你的POJO似乎很完美。

所以不，没有争用，你的可扩展性将是完美的。

• 您无需支付额外费用。
• 你甚至少了，因为你有一个实例而不是几个
• 您的可扩展性更好，因为您永远不会达到游泳池的限制（您没有）。