@Stateless vs @RequestScoped [英] @Stateless vs @RequestScoped

问题描述

我正在学习使用JAX-RS进行一些安静的api开发，并且我的资源类有问题。

I am learning to use JAX-RS for some restful api development and have an issue regarding my resource classes.

我的理解是我的资源类应该是RequestScoped，但是，
当它是RequestScoped我调用实体管理器的persist方法时抛出TransactionRequiredException。

My understanding is that my resource class should be RequestScoped, however, when it is RequestScoped my call to the entity manager's persist method it throws a TransactionRequiredException.

如果我将我的资源类更改为无状态，那么一切都很好，实体管理器可以保持没有任何问题。

If I change my resource class to be Stateless then everything is fine and the entity manager can persist without any issue.

我还是JavaEE的新手，想知道为什么会发生这种情况以及@Stateless注释可以让持久化上下文正确注入。
我还想知道JAX-RS资源类是否是无状态而不是RequestScoped有任何问题，因为我见过的大多数教程都有。

I am still new to JavaEE and would like to know why this happens and what the @Stateless annotation does that allows the persistence context to inject correctly. I would also like to know if there is any problem with JAX-RS resource classes being stateless instead of RequestScoped as most of the tutorials I've seen have them.

我在下面列出了一些示例代码来说明。

I have included some example code below to illustrate.

@Path("Things")
//@Stateless //works just fine when em.persist() is called
@RequestScoped //throws transactionrequiredexception when em.persist() is called
public class ThingsResource{

    @PersistenceContext(unitName = "persistenceUnitName")
    EntityManager em;


    public ThingsResource() { }

    @POST
    @Produces(MediaType.APPLICATION_JSON)
    public Response postThing(ThingDTO thing){

        ThingEntity newThing = new ThingEntity(thing);
        em.persist(newThing);
        em.flush();

        return Response.created(new URI("/" + newThing.getId()).build();

    }
}

推荐答案

马蒂亚斯现货。

@Stateless带注释的bean是一个EJB，它默认提供 Container -Managed-Transactions 。如果EJB的客户端没有提供一个事务，CMT将默认创建一个新事务。

A @Stateless annotated bean is an EJB which by default provides Container-Managed-Transactions. CMT will by default create a new transaction if the client of the EJB did not provide one.

必需属性如果客户端在事务中运行而
调用企业bean的方法，则该方法在
客户端的事务中执行。如果客户端未与$ b关联$ b transaction，容器在运行
方法之前启动一个新事务。

Required Attribute If the client is running within a transaction and invokes the enterprise bean’s method, the method executes within the client’s transaction. If the client is not associated with a transaction, the container starts a new transaction before running the method.

Required属性是所有
企业bean的隐式事务属性使用container-m运行的方法年度交易
划界。除非
需要覆盖另一个事务属性，否则通常不会设置Required属性。因为
事务属性是声明性的，所以你可以稍后更改它们
。

The Required attribute is the implicit transaction attribute for all enterprise bean methods running with container-managed transaction demarcation. You typically do not set the Required attribute unless you need to override another transaction attribute. Because transaction attributes are declarative, you can easily change them later.

在最近的java-ee中-7 tuturial on jax-rs，Oracle有使用示例EJB（@Stateless）。

In the recent java-ee-7 tuturial on jax-rs, Oracle has example of using EJBs (@Stateless).

... EJB的@ javax.ejb.Asynchronous注释和
@Suspended的组合AsyncResponse支持异步执行
业务逻辑，并最终通知感兴趣的客户端。
任何JAX-RS根资源都可以使用@Stateless或
@Singleton注释进行注释，并且实际上可以用作EJB ..

... the combination of EJB's @javax.ejb.Asynchronous annotation and the @Suspended AsyncResponse enables asynchronous execution of business logic with eventual notification of the interested client. Any JAX-RS root resource can be annotated with @Stateless or @Singleton annotations and can, in effect, function as an EJB ..

在这种情况下，@ RequestScoped与@Stateless之间的主要区别在于容器可以汇集EJB并避免一些昂贵的构造/销毁操作，否则这些操作可能需要在每个bean上构建请求。

Main difference between @RequestScoped vs @Stateless in this scenario will be that the container can pool the EJBs and avoid some expensive construct/destroy operations that might be needed for beans that would otherwise be constructed on every request.

这篇关于@Stateless vs @RequestScoped的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！