为什么无状态EJB被集中？

应用服务器为什么要共享无状态EJB？为什么无状态EJB被集中？

我可以理解，控制调用应用程序的工作负载非常有用，但这仅仅证明了使用调用者客户端将服务器作为FAÇADE的EJB池化。

将内部EJB（那些没有公开并且只在内部调用来执行业务逻辑）集中起来有什么好处吗？而不是使用共享单个实例（就像Spring一样）。

我至少可以考虑一个缺点：高度使用的内部EJB可能会成为瓶颈。

来源

2012-01-16 edutesoy

无状态会话bean EJB不一定是线程安全的。他们可以持有像JMS会话这样的资源，这些资源一次不能与多个线程共享，因此服务器会将它们汇集到一起，以便它可以同时为同一个bean提供多个请求（JMS资源也是共享的，但我只是使用这个例子）。

来源

2012-01-16 19:02:31 Dev

如果它是无状态的，那么没有状态被并发威胁，那么没有竞争条件可以出现，因此它们是线程安全的，我错了吗？是的，我知道他们有一些状态，比如注入资源，但是也许他们不应该被称为无状态！ :)我认为答案是正确的。 – edutesoy 2012-01-17 09:33:28

@edutesoy我同意你的解释。但是为什么国家仍然维持。 – 2014-05-14 04:53:39

我也想知道为什么无状态的EJB被汇集起来。但我想知道他们为什么汇集而不是按需创建和销毁。实例可以被重复用于不相关请求的事实使得无状态bean的实现变得复杂（这意味着你必须非常小心地使用实例字段），并且我没有看到任何显着的好处。

具体来说，我没有看到任何性能上的好处。我在JBoss（6，IIRC）中介绍了无状态bean的实现，以及它的唯一bean集合实例本身;处理方法调用的管道在每次使用时都会从头开始重新创建。这意味着唯一的性能节省是单个对象创建，这应该是一个微不足道的时间。我可以看到它是不平凡的唯一情况是，如果bean获得重量级资源，并在调用之间持有它们。然而，在那种情况下，这个bean真的被用作一个荣耀的，管理不善的池子;正确的解决方案将是直接汇集资源！

现在，EJB已经存在很长时间了。当他们第一次出来的时候，物体的创造是昂贵的，所以将它们合并是有意义的。但那些日子早已逝去。为什么在EJB3中池不会丢失？

来源

2012-01-16 19:32:31

好吧，我想如果你有成千上万的并发请求，只要你确定它们是线程安全的，而不是在内存中有成千上万的实例，将它们集中起来，或者甚至更多，将它们创建为@Singleton是有意义的。 – 2012-01-16 23:29:46

如果bean是线程安全的，那么是的，单例是理想的。但是，如果不是，汇集和丢弃实例的内存负载将是相似的;混合实例实际上会让垃圾收集器*做更多工作，因为它们活得足够长以逃离托儿所。 – 2012-01-16 23:42:11

这是一个很大的说法。我想这取决于每个请求处理的时间，以及这些对象在池中花费的时间。如果它们中的大多数可以在任何时间点使用，那么您可能会比创建/销毁获得一些好处。这也取决于流量趋势等。这是非常细粒度的分析IMO :) – 2012-01-17 00:01:30

为什么无状态EJB被集中？

回答

相关问题