I am learning to use JAX-RS for some restful api development and have an issue regarding my resource classes.
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.
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();
}
}
When you don't want to make your root resource as an EJB (by annotating it with
@Stateless
), you can use aUserTransaction
.Matthias is spot on.
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.
In the recent java-ee-7 tuturial on jax-rs, Oracle has example of using EJBs (@Stateless).
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.