为什么要合并无状态会话bean?

时间:2020-03-06 14:44:12  来源:igfitidea点击:

Java中的无状态Bean不会在两次客户端调用之间保持其状态。因此,简而言之,我们可以将它们视为具有业务方法的对象。每种方法都带有参数并返回结果。调用该方法时,将在执行堆栈中创建一些局部变量。当该方法返回时,将本地对象从堆栈中删除,如果分配了一些临时对象,则无论如何都会对其进行垃圾回收。

从我的角度来看,这与通过单独的线程调用同一实例的方法没有什么不同。那么,为什么容器不能使用bean的一个实例而不是池化多个实例呢?

解决方案

池化有几件事情。

一个,通过每个实例拥有一个bean,可以确保我们是线程安全的(例如,Servlet不是线程安全的)。

第二,我们减少了bean可能具有的任何潜在启动时间。尽管会话Bean是"无状态的",但就客户端而言,它们仅需要是无状态的。例如,在EJB中,我们可以将多个服务器资源注入到Session Bean中。该状态是Bean专用的,但是没有理由不能使它在调用之间保持不变。因此,通过池化bean,可以将这些查找减少为仅在创建bean时进行。

第三,可以使用bean池来限制流量。如果一个池中只有10个Bean,那么最多只能同时处理10个请求,其余的将排队。

Statelesss会话Bean的生命周期不存在,处于被动状态和MethodReady(被动或者非活动)状态。要优化性能,而不是通过从创建状态到方法就绪状态遍历整个Bean,容器通过以下方式在主动状态和被动状态之间进行管理容器通过管理Bean池在那里回调ejbActivate()和ejbPassivate()。

花生

合并可提高性能。

一个处理所有请求/线程的实例将导致大量争用和阻塞。

由于我们不知道将使用哪个实例(并且多个线程可以同时使用一个实例),因此Bean必须是线程安全的。

容器可以根据实际活动来管理池的大小。

Java EE模型的事务性使用线程上下文来管理事务生命周期。

存在这种简化,因此无需实现任何特定的接口即可直接与UserTransaction对象进行交互;当从InitialContext检索事务(或者将其注入会话Bean)时,它将绑定到线程局部变量以供重用(例如,无状态会话Bean中的方法调用另一个也使用注入事务的无状态会话Bean)。 )