1

This is complementary to my other question, I don't understand how "scoping" works is in Java-EE. In fact the terminology such as "scope" and "session" used regarding EJB's and CBI seems to be completely confused.

But ignoring the confusing terms, what actually happens ? For example let's say we have a servlet in the web tier. We might want to have a stateful EJB to keep information either for 1) an entire HTTP session consisting of back and forth requests 2) a single HTTP request, though the EJB methods may be called multiple times by the servlet for the same request, so we still need a stateful bean to hold state between the multiple calls to it despite only having one HTTP request. And so on with the other types...

My question is, CDI seems to provide these options, however prior to CDI, and now if not using CDI, how did/do EJB's handle the difference between a session scope and a request scope? The term session beans seem to be misleading as they do not seem to refer to http session. In fact it seems like "stateful" is what actually could be tied to an http session.

If I understand correctly the CDI container keeps track of an HTTP session by using cookies or other fallback methods and that is how it is able to know when to destroy session scope beans, does the EJB container also keep track of the http session ? Or do they both use the same plumbing to keep track of the session ? Any insights are greatly appreciated into this highly confusing area,

Thanks

  • [Related/Duplicate](http://stackoverflow.com/questions/26305295/how-is-the-requestscoped-bean-instance-provided-to-sessionscoped-bean-in-runti/26311504#26311504) – kolossus Apr 13 '15 at 04:32

1 Answers1

4

In fact the terminology such as "scope" and "session" used regarding EJB's and CBI seems to be completely confused.

Yes, the term "session" is overloaded between EJB and servlet. For EJB, the duration of a "session" is at the method-level: either the bean instance you're calling is "stateless session bean", which doesn't remember state even if the same client calls it, or "stateful session bean", which gives each client its own bean instance that survives until it times out or is explicitly removed. (Or singleton in EJB 3.1.) For servlet, "session" always means something that stores state, typically identified by a cookie so that it can persist over several requests. As you say, a stateful session bean might be useful even within a single web request, with or without a servlet session.

CDI seems to provide these options, however prior to CDI, and now if not using CDI, how did/do EJB's handle the difference between a session scope and a request scope?

EJB "request scope" would be stateless session beans: you get a new instance every time you call an EJB method. EJB has no concept of "servlet session scope". The closest you can get is to create a stateful session bean and store it in the HttpSession yourself.

CDI scopes are two things: proxies that mediate access to the actual bean instance in order to "magically" operate on a scoped object, and a mechanism for getting/setting state for the scope. For @SessionScoped @Stateful, that means CDI is just doing the grunt work: it creates the stateful bean when you first use the proxy, it stores the instance in HttpSession, and it registers a listener with the HttpSession so that it can destroy the stateful bean when the HttpSession ends.

Brett Kail
  • 33,593
  • 2
  • 85
  • 90
  • So that means if I inject a Stateful EJB into a servlet and do not store it in the HttpSession, then the EJB will be tied to the servlet instance and not to an http session? That raises the question, what is the servlet instance lifecycle? Does each web client get a seperate servlet instance or are they reused between clients? On the other hand if I use CDI SessionScoped for the EJB, then it will be automatically tied to the actual http session of a single user, regardless of whatever the container may be doing with the servlet instance, is this correct? I appreciate your help, thanks. –  Apr 12 '15 at 05:21
  • The same servlet instance is shared by all requests on all threads, so it never makes sense to `@EJB`-inject a stateful session bean into a servlet. Your description of `@SessionScoped` stateful session bean is correct. (Of course, keep in mind that a single user could still make several simultaneous requests, but stateful session bean access timeouts or transaction affinity can help.) – Brett Kail Apr 12 '15 at 18:08