EJB Pooling vs Thread-safe和@PreDestroy

Question

我无法理解EJB容器如何管理@Stateless具有实例变量的bean的线程安全性.在解释我的担忧之前,我将举一个简单的例子:

@Stateless
public class BeanTest{

@Inject
private String var;

private Connection connection;

@Resource(name = "jdbc/TestDB")
private DataSource dataSource;

public void modify() {
    var = "TestName";
}

@PostConstruct
public void initialize() {
    try {
        connection = dataSource.getConnection();
    } catch (SQLException sqle) {
        sqle.printStackTrace();
    }
}

@PreDestroy
public void cleanup() {
    try {
        connection.close();
        connection = null;
    } catch (SQLException sqle) {
        sqle.printStackTrace();
    }
}
}

这是我的问题,假设我们的容器支持池:

1.池与线程安全:

用户1使用了一个实例BeanTest并var使用modify方法修改了,然后他完成了并且容器将实例放入BeanTest托管池中.当用户2尝试对请求使用相同的bean时,他可能会获得BeanTest由用户1初始修改的相同实例(我知道可能还会获得另一个实例).那么var他会找到哪个实例变量状态(默认值是null或"TestName")？如果它是新修改的那个,这是否意味着即使@Statelessbean不是100%线程安全的？所以finnaly没有添加容器 - 关于线程安全的值,因为不使用实例变量使得bean线程安全,即使它不是@Statelessbean

2. Pooling vs @PreDestroy

如果bean被返回到托管池而没有被销毁,那么这是否意味着@Predestroy不会调用该方法,在这种情况下连接将保持打开状态？那么,如果我们在池中有30个inft,我们可能有30个未使用的开放连接,这不是性能问题吗？或者这不是如何@Predestroy与汇集相结合？(使用Connection只是一个例子,我们可能有其他需要关闭的资源@Predestroy)

注意: 这不是一个真实的例子,所以我不是在寻找替代解决方案,我关心的是了解整个概念以及如何在Application Server中管理事物,在幕后发生了什么

Answer 1

我认为你所指的线程安全是不可重入条款

容器提供商的责任 Enterprise JavaBeans 3.2，最终版本会话 Bean 组件合同 2013 年 4 月 10 日下午 2:59 Oracle

4.10.13 不可重入实例 容器必须确保任何时候只有一个线程可以执行无状态或有状态会话 bean 实例。因此，有状态和无状态会话 Bean 不必编码为可重入。此规则的一个含义是应用程序无法对无状态或有状态会话 Bean 实例进行环回调用

您可以在无状态会话 bean 中忽略 EJB 编程限制，创建一堆线程并执行非线程安全的操作。容器不会阻止你。由于线程管理冲突，这可能会导致各种错误。

容器只承诺一次只允许1个线程访问无状态ejb。（关于单例有一些不同的规则）

你是对的，如果实例返回到示例中的连接可以建立的池中。因为当然，been 实例仍然存在。

如果您深入研究应用程序服务器文档，即 Glassfish EJB 池调整章节，您会发现默认情况是销毁对象实例而不是将它们返回到池中。与 JDBC 连接相同，它将被关闭并清理。重用是一种选择，在这种情况下，如果您尝试在 SSB 中创建状态，可能会消耗一些额外的内存。我认为如果实例在池中闲置，不会对性能产生太大影响。

确切的池实现取决于应用程序服务器供应商，只要他们遵守规范即可。我想你会发现默认行为是在使用后销毁实例。这会导致托管资源被清理。

但所有这些都是静音，在您的示例中，您试图在类中存储状态（连接字段）。无需在无状态组件中创建状态，这不是此类组件的用途。Java EE 架构的其他部分处理状态。（实体、statefulbean、JCA）