Request scoped context for stateless session beans

Question

Is there a request-scoped context for EJB3 session-beans? My environment is Java-EE-5.

This example

@Remote(SessionFacade.class) @Stateless
public class SessionFacadeBean implements SessionFacade {
  @EJB
  private Other bean;

  public void myBusinessMethod() {
     // TODO: get or create *myRequestScope*
     *myRequestScope*.put("demo", Integer.valueOf( 1 ));
     bean.otherBusinessMethod();
     sysout(*myRequestScope*.get("demo"));
  }
}

@Local(Other.class) @Stateless
public class OtherBean implements Other {
  public void otherBusinessMethod() {
     // TODO: get or create *myRequestScope*
     *myRequestScope*.put("demo", Integer.valueOf( 2 ));
  }
}

should always printout "2" when invoking SessionFacadeBean#myBusinessMethod() - irrespective of parallel invocations.

I do not have the luxury of using CDI. And, it should also work independently of transaction propagation (so JCA is also not an option).

score 1 · Answer 1 · answered Jun 05 '11 at 10:08

1

Stateless EJBs, are their name suggests do not store state, so there is no concept of request-scope. There is a session scope that is limited to the current runtime session context, where you cannot store state as well, so that rules out any option of storing state within the bean or within the container.

You might find some luck by using ThreadLocal variables, but this as the name suggests, is scoped to the current thread of execution. Going by your posted code, this appears to be what you would want. The problem with this approach is that,

Thread objects are simply not destroyed once the EJB method has completed execution; they are returned to the container's thread pool. Therefore, if you read the ThreadLocal value in a different context of execution, you will find the value of the previous execution context that used the same thread. In other words, ensure that your application always puts values in the ThreadLocal object before reading them.
Additionally, free any ThreadLocal objects once you do not require them, otherwise you would have a memory leak on your hands.

answered Jun 05 '11 at 10:08

Vineet Reynolds

76,006
17
150
174

Statelessnes is not the problem here. Servlets are also stateless. If my SLSF were a webservice, I could get a [`WebServiceContext`](http://download.oracle.com/javaee/5/api/javax/xml/ws/WebServiceContext.html) injected - which is a request scope par excellence. Still looks like a gap in the specification to me. – Frank Schwarz Jun 05 '11 at 13:11
(I previously had an comment regarding EJBContext.getContextData, but that won't do what you want. Sorry.) – Brett Kail Jun 07 '11 at 01:17
Stateless do store state! Conversational state, valid during method invocation! – dalvarezmartinez1 Oct 07 '14 at 13:59
@justin.hughey Is that for Java EE 5? Read the question. – Vineet Reynolds Jun 26 '15 at 08:15
Did I say it was? Is it provided as an "Answer"? While I did not give additional context it wasn't intended as an answer. Googling this problem in a non-EE5 context brings you here. That was my intent to help others. Sorry if that is unacceptable. – justin.hughey Jun 27 '15 at 14:50

score 0 · Answer 2 · answered Jun 05 '11 at 10:08

Is there a request-scoped context for stateless session-beans?

Short answer is No.

The long answer is: You need some context to share data between invocations of your business methods. This could be a design issue. Requestscope is a concept of web-tier.

In the Web-tier the request,page,session and application scope is implemented as a Hashmap. So you could pass a reference to a Hashmap as context to share all data.
Another approach could be to use a singleton (which needs to be shared between nodes e.g. using ehcache).
Migrate to EJB 3.1 and use @Singleton
Consider to use stateful Beans and put your request-scope into the beans session scope which could be removed after you leave the request scope.

A stateful session bean (in the sense of a shopping cart to push around) is not working either. If I use the @EJB-injection mechanism, the OtherBean-instance does not get the same SFSB instance as the SessionFacaceBean-instance — Frank Schwarz, Jun 05 '11 at 10:21

Request scoped context for stateless session beans

2 Answers2