Search code examples
javacdiejb-3.1weblogic12c

Does EJB_Y (called by EJB_X) need to be annotated as "@Stateful" in order to be thread safe?

PREMISE:

  1. stateless EJB_X contains annotated reference to EJB_Y (e.g., "@EJB EJB_Y")

  2. EJB_X needs to initialize EJB_Y before calling its business methods

  3. Suppose that EJB_X both (a) initializes and then subsequently (b) calls EJB_Y's business method(s) - i.e., a "multi-step" process(?)

QUESTION:

Does EJB_Y need to be annotated as "@Stateful" in order to be thread safe?

NOTE:
Would otherwise have EJB_Y be just a simple POJO (e.g., POJO_Y) - however, it seems that, in order to have an logging "@Interceptor" class access method parameters used EJB_X's call to EJB_Y's business methods, EJB_Y must be an EJB (?)...

Other info:

a. EJB 3.1

b. EJB_X exposes REST methods

c. currently relegated to WebLogic 12.1.3 running JDK 1.8.x

Solution

  • A question:

    1. What do you mean by EJB_X initializes EJB_Y ? It is the container that initializes EJB.

    And few points:

    1. EJB exposing a rest service is allowed, but from Oracle point of view, exposing your business logic it's a kind of "quick and dirty" approach that should be revisited in the nearest future (I clearly remember this question from my architect exam). To simplify, an EJB should be the back end of a rest service, or better, a web service should stay in the integration layer.
    2. A stateless EJB and all subsequent calls to other stateless EJB are thread safe, and thread safety is guaranteed by the container (weblogic in this case) no need to make it stafeful. If you need multi thread in the EJB world look for @Singleton
    3. Just to speak, I have always found the word stateless and stateful from Sun/Oracle a little misleading, I would have said conversationless and conversationful since the beginning, if english language allow it :-)

    [UPDATE]

    It does not make sense to invoke a SFSB from a SLSB. In the end you will have unpredictable results, just because of the nature of SLSB of living in a pool and being shared among clients. You will also loose one of the most important benefit of a SLSB: scalability.

    I don't know much about your architecture and design, but I would revisit the web service layer by getting rid of the front end EJB and structuring instead a class to behave as a web service (by use of annotation). Then, if you want to stay in the EJB world, pass all your data within the EJB invocation context, and then retrieve it from the EJB itself.