多线程servlet;单线程EJB

发布于 2024-10-08 18:27:13 字数 158 浏览 0 评论 0原文

在传统的 n 层 Web 应用程序中,servlet 用于 Web 层,ejbs(2.0) 用于业务层,使 servlet 模型多线程而 ejb 模型单线程的基本原理是什么?
即所有请求只有1个servlet实例,但对于ejbs来说,对于每个请求,都会从bean池中分配一个新的bean实例。

In a traditional n tier web app with servlets for web layer and ejbs(2.0) for biz layer, what is the rationale behind making the servlet model multi threaded and the ejb model single threaded?
i.e there is only 1 servlet instance for all requests, but for ejbs, for each request, there is a new bean instance assigned from the bean pool.

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

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

发布评论

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

评论(2

你又不是我 2024-10-15 18:27:13

特定 Servlet 确实只有一个实例,因为它们应该是无状态的。实际上,情况并非总是如此,但也只能这样了。

然而,有多个无状态会话 Bean (SLSB) 实例,并且这些实例是池化的。

根据其定义,无状态会话 Bean 是无状态的,因此从表面上看,这似乎是一个悖论。问题是,虽然无状态会话 Bean 对于对它们进行的单独调用来说是无状态的,但实际上它们通常具有状态。

此状态采用对其他资源的引用的形式。 线程安全的JPA实体管理器就是一个典型的例子。在对无状态会话 bean 的单次调用期间,调用者必须具有对此资源的独占访问权。当调用返回时,下一个调用者可以拥有独占访问权限,等等。

如果使用单个实例,那么所有调用者要么必须互相等待(这当然会影响性能),要么他们将拥有此访问权限单实例并发。在后一种情况下,bean 实现者必须手动锁定非线程安全资源,例如实体管理器,这通常很脆弱、容易出错,并且最终仍然导致调用者等待每个资源。其他。

因此,为了提高性能并仍然有安全保证,正在使用多个实例。

然后,这些实例将被集中并重新使用,而不是为每个请求重新创建,因为查找、初始化和注入 bean 所需的所有依赖项可能会非常耗时。

因此,所有这些自动意味着如果您将实体管理器或其他非线程安全资源注入到 Servlet 中(这是允许的),您可能会遇到问题。这是 Java EE 架构中的一个小漏洞,当然可以通过简单地使用无状态会话 bean 轻松解决。

There is indeed only one instance for a specific Servlet since they are supposed to be stateless. In practice this isn't always the case, but so be it.

There are however multiple instances of Stateless session beans (SLSB), and those are pooled.

By their very definition, stateless session beans are stateless, so on the surface this seems like a paradox. The things is that while stateless session beans are stateless with respect to individual calls being made to them, they in fact very often have state.

This state is in the form of references to other resources. The JPA entity manager, which is not thread-safe, is a prime example here. During a single call to a stateless session bean, the caller must have exclusive access to this resource. When the call returns, the next caller can have exclusive access, etc.

If a single instance was used, then either all callers would have to wait on each other (which is of course killing for performance), or they would have the access this single instance concurrently. In the latter case, the bean implementor has to do manual locking of the non thread-safe resources like the entity manager which is often brittle, error-prone and in the end still causes callers to wait on each other.

So, in order to improve performance and still have the safety guarantee, multiple instances are being used.

Those instances are then being pooled and re-used instead of created fresh for each request, because finding, initializing and injecting all required dependencies of the bean can potentially be time consuming.

All of this thus automatically also means that if you inject an entity manager or other non thread-safe resource into a Servlet (which is allowed), you may run into problems. This is a small loop-hole in the Java EE architecture, which is of course easily worked around by simply making use of stateless session beans.

桃气十足 2024-10-15 18:27:13

我认为 Servlet 通常为 EJB 中实现的繁重逻辑提供了薄弱的外观。 Servlet 应该是无状态的,因此没有理由创建同一 Servlet 的多个实例。

如果您仅使用无状态 bean,我认为没有理由也有多个实例。但有状态 EJB 具有状态,因此每个并发请求都需要实例。

我希望我没有说废话。

I think that typically servlets present thin facade to the heavy logic implemented in EJBs. Servlets should be stateless and therefore there is no reason to create more than one instance of the same servlet.

If you are using stateless beans only I think that there is no reason to have more than one instance too. But statefull EJBs have state and therefore you need instance per simultaneous request.

I hope I did not say bullshit.

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