EJB3 如何确保在删除 bean 之前发生事情

发布于 2024-11-25 01:47:51 字数 253 浏览 1 评论 0原文

假设我让我的客户使用 Stateful Session Bean 预订飞机上的座位。如果客户端显式调用我的Remove方法,那么他的所有保留都将被取消,并且该bean随后将被删除。

但是,如果客户端空闲一段时间并且 Bean 被钝化,如果 Bean 在钝化时超时,它将被删除,而不会调用我的任何函数。因此,如果有人能告诉我如何确保在 bean 被删除时预订会被取消,我将非常感激。如果我使用@PreDestroy注解,可以解决这个问题吗?

此致, 詹姆斯·特兰

Suppose I let my customer reserve seats on a plane using Stateful Session Bean. If the client explicitly calls my Remove method, all of his reservations will be cancelled and the bean is removed afterward.

However, in case the client is idle for some time and the Bean get passivated, if the Bean times out while being passivated, it would be deleted without calling any of my functions. Hence, I'd be very grateful if someone could show me how I can make sure that the reservations would be cancelled if the bean get deleted. If I use the @PreDestroy annotation, will it solve this problem?

Best regards,
James Tran

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

月下凄凉 2024-12-02 01:47:51

@PreDestroy 方法很可能不会被调用。 EJB 3.1 规范明确指出:

4.6.3 错过的预销毁呼叫

Bean Provider 不能假设容器总是会调用
PreDestroy 生命周期回调拦截器方法(或 ejbRemove
方法)用于会话 bean 实例。以下场景会导致
PreDestroy 生命周期回调拦截器方法不存在
调用实例:

• EJB 容器崩溃。

• 从实例的方法向容器抛出的系统异常。

实例处于被动状态时客户端不活动的超时。超时由部署者以特定于 EJB 容器实现的方式指定。

该规范还详细说明了如果在这种情况下不调用 @PreDestroy 方法,如何删除资源:

例如,如果购物车组件作为会话实现
bean,会话 bean 将购物车内容存储在
数据库,应用程序应该提供一个运行的程序
定期并从数据库中删除“废弃”的购物车。

就您而言,这取决于您存储预订状态的方式。如果它们保留在数据库中,那么我建议采用与规范中规定的相同的方法。您可以使用 EJB 计时器服务定期执行此活动,或者使用 Quartz 等调度程序。请注意,必须区分不再存在的钝化会话 bean 实例的内容和将再次准备好的会话 bean 实例的内容。

It is quite possible for the @PreDestroy method to not be invoked. The EJB 3.1 specification, explicitly states this:

4.6.3 Missed PreDestroy Calls

The Bean Provider cannot assume that the container will always invoke
the PreDestroy lifecycle callback interceptor method(s) (or ejbRemove
method) for a session bean instance. The following scenarios result in
the PreDestroy lifecycle callback interceptor method(s) not being
called for an instance:

• A crash of the EJB container.

• A system exception thrown from the instance’s method to the container.

A timeout of client inactivity while the instance is in the passive state. The timeout is specified by the Deployer in an EJB container implementation-specific way.

The specification also details how resources may be removed if the @PreDestroy method is not invoked in such scenarios:

For example, if a shopping cart component is implemented as a session
bean, and the session bean stores the shopping cart content in a
database, the application should provide a program that runs
periodically and removes “abandoned” shopping carts from the database.

In your case, it would depend on how you are storing the state of your reservations. If they are persisted in the database, then I would suggest employing the same approach as mandated in the specification. You could use the EJB Timer service, to perform this activity periodically, or use a scheduler like Quartz. Note, that it is imperative to distinguish between the contents of passivated session bean instances that no longer exist, and those that will be made ready once again.

夏至、离别 2024-12-02 01:47:51

钝化的 bean 将在超时时被销毁,因此任何用 @PreDestroy 注释的方法都将执行您正在寻找的操作。

当 A 处于活动状态时,A 的 Stateful bean 实例不会与 B 共享,直到 A 的实例被销毁。请参阅本文中的图表供进一步阅读

A passivated bean will get destroyed on timeout and hence any method annotated with @PreDestroy will do what you are looking for.

While A is active, A's instance of the Stateful bean will not be shared with B until A's instance is destroyed. See the diagram on this article for further reading

一曲琵琶半遮面シ 2024-12-02 01:47:51

是的,应该的。用@PreDestroy注释的方法将在bean删除之前被调用(即使i在钝化状态下超时)

Yes it should. The method annotated with @PreDestroy will be called prior to bean removal (even if i times-out in the passivated state)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文