Diff between @SessionScoped (CDI) and @Stateful (Java EE)

Question

I learned that CDI Beans can be used in different web-application-based scopes (only there, right?). For example: @RequestScoped, @SessionScoped and so on. @SessionScoped hold the data in a managed bean over the complete browser-session. That sounds quiet logically, because the annotations name describes what it does. However - now I had a closer look at EJB session beans. So far I know, that such a been could have one of three states: @Stateless, @Stateful and @Singleton. For me, it looks like there is a direct comparability between those and the annotations of a CDI bean: @RequestScoped --> @Stateless, @SessionScoped --> @Stateful , @ApplicationScoped --> @Singleton. But since I was studying some examples, I found a bean which includes both the @Stateful and the @SessionScoped annotation. I looked for an explaination - but I did not find any answer which was understandable. So, what exactly is the difference? Why do I have to use both annotations? Thank you.

Answer 1

CDI Beans can be used in different web-application-based scopes (only there, right?).

Wrong. CDI beans can be used in any place you desire - DB connection/communication, bussiness logic, event-based programming even in Java SE (Weld, reference implementation of CDI, offers this even now). However, specifically @SessionScoped bean make much more sense in HTTP sessions than anywhere else. But still you can imagine (and use) session as a given period of time with marked beginning and end. And within those boundaries, session exists - doesn't need to be HTTP session, but it is the most obvious one.

direct comparability between those and the annotations of a CDI bean: @RequestScoped --> @Stateless, @SessionScoped --> @Stateful , @ApplicationScoped --> @Singleton.

Wrong again. EJBs are only linked to web communication, CDI is not. Also based on which annotation you chose, you also pick a container (CDI/EJB) which will take responsibility for that bean. CDI integrates all EJB beans (creating a proxy and making it "seemingly" a CDI bean - allowing you to use CDI stuff inside EJB bean).

Now for instance, @Stateless is in CDi/Weld internally represented as a @Dependent scope and not as @RequestScoped because @Stateless beans in EJB are re-used and you cannot really on what is their state. While with @RequestScoped in CDI, you activate the request context (let's stick to HTTP, so by sending something you activate it) which triggers creation of all @RequestScoped beans. After the request all those beans are destroyed , never used again. So you can fully rely on what you put inside and you can also be sure that it won't live after the request.

Another story is @ApplicationScoped versus @Singleton . These are indeed very similar and the most significant detail would probably be the fact that CDI creates its own proxies of the beans. But that would be too detailed for this question, I think you can now deem them comparable.

Diff between @SessionScoped (CDI) and @Stateful (Java EE)

Now finally to the original question. I think to grasp these differences in general you need to understand the fact that CDI operates on contexts . It always activates context (session context in this case) and at that moment a set of @SessionScoped beans come to existence and you can communicate with them and they have values and states etc. The contexts interlope so in the same time a request context may exist and app context does exist for sure. So we can say that @SessionScoped is tied to the session and controlled by the container, while @Stateful offers you a user-managed session with its lifetime managed by a client and it also adds a lot of other features on top of that.

The reason why you can sometimes see both annotations on one bean is that people combine them to get best of both worlds - container managed lifecycle and added features. But note that while @Stateful isn't used much these days (it usually makes more sense to opt-in for @Stateless ), @SessionScope is much more universal and fits into nearly any session-based scenario.

Hope it sheds at least some light, it is a very complex topic I am afraid.

Answer 2

EJB Beans by default giving you Transaction, CDI Beans don't.

I think that's the difference