有状态会话 bean 池大小

Question

我正在浏览企业会话 bean 材料。我对以下几点有疑问：-

1) 假设我们提到某些静态会话 bean 的池大小为 50。不同的 50 个客户使用它们。 所以现在所有 50 个 bean 都保持某种状态。这些状态将在什么时间点被删除，以便 如果第 51 位客户要 bean，它不会得到任何以前被宠坏的状态。？

2) 假设我们提到某个无状态会话 bean 的池大小为 50，并且所有这些 bean 都在使用中 时间点。如果第 51 个客户来要一个 bean，那会等到某个 bean 空闲吗？ 或创建新的 bean 实例？

Answer 1

有状态会话 bean 通常不会被池化。这是可能的，但是它们的状态使它们不太适合池化，因为客户端在获取引用时期望一个新的 bean。

对于无状态 bean，是的，第 51 个客户端必须等待。这通常是一件好事，因为它会自动调节系统的资源消耗。根据您拥有的资源、您的工作量和单次调用 ssb 的工作量，您可能需要调整池的大小。

Answer 2

正如 bkail 所说，@Stateless bean 的池化语义是特定于供应商的。也就是说，在 EJB 3.1 中，我们添加了 @AccessTimeout 注释，该注释可用于 @Stateless、@Stateful 或 @Singleton bean 的 bean 类或方法。

@AccessTimeout

在一般意义上，此注释可移植地指定如果并发访问出现等待条件，调用者将等待多长时间。具体到每种bean类型，等待条件会出现在：

• @Singleton - 正在调用 @Lock(WRITE) 方法并使用容器管理的并发性。所有方法默认为@Lock(WRITE)。
• @Stateful - 正在调用实例的任何方法并发生第二次调用。或者 @Stateful bean 在一个事务中，而调用者正在从该事务之外调用它。
• @Stateless - 池中没有可用的实例。然而，如前所述，如果有的话，汇集语义不包含在规范中。如果供应商的池语义确实涉及等待条件，则应应用 @AccessTimeout。

用法

@AccessTimeout 只是对java.util.concurrent API 中常用的long 和TimeUnit 元组的便捷包装。

import java.util.concurrent.TimeUnit;
@Target({METHOD, TYPE})
@Retention(RUNTIME)
public @interface AccessTimeout {
    long value();
    TimeUnit unit() default TimeUnit.MILLISECONDS; 
}

当在 bean 类或方法上显式设置时，它具有三种可能的含义：

• @AccessTimeout(-1) - 永远不要超时，只要等待就可以。可能永远。
• @AccessTimeout(0) - 永远不要等待。如果出现等待条件，请立即抛出 ConcurrentAccessException。
• @AccessTimout(30, TimeUnit.SECONDS) - 如果出现等待条件，最多等待 30 秒。之后，抛出ConcurrentAccessTimeoutExcpetion

无标准默认

注意value 属性没有默认值。这是有意的，旨在传达如果未明确使用@AccessTimeout，您获得的行为是特定于供应商的。

有些厂商会等待一个预先配置的时间并抛出javax.ejb.ConcurrentAccessException，有些厂商会立即抛出它。当我们定义这个注解时，很明显我们所有的供应商都在做一些不同的事情，强制执行默认设置会导致现有应用出现问题。

类似地，在 EJB 3.0 之前，没有默认事务属性，并且每个供应商都不同。谢天谢地，EJB 3.0 的不同之处足以让我们最终说：“对于 EJB 3.0 bean，默认值是必需的。”