Welcome to Lesson 3, stateful session beans. In this lesson we will actually talk about two types of beans that maintain state singleton session beans scoped to the entire application and we'll create and deploy a stateful session bean whose scope can be defined such as tourism session. We'll maintain state in a stateful session bean and we'll use CDI to inject a stateful session bean into a servlet, but have that injected bean scoped only to an HTTP session. What that means is, once the client has finished with it, it will be destroyed and when a new request comes in and creates a new session, a new instance of stateful session bean would be created with its own state. A singleton session bean is a bean that's instantiated once per application or in a distributed environment once per JVM. The instance lives for the entire life of the application and is intended to be shared by all resources of that application. We annotate it with the at singleton annotation from javax.ejb package. If we decide to maintain state in this type of bean, it will be shared by any client through out the application. If we give it mutable state, that means that potentially any part of the application could update the state which is then subsequently shared. Initialization is up to the container but it's guaranteed to occur before the first call to the singleton, however, frequently we use annotations to dictate this ourselves such as here we used at startup which means that the singleton will be initialized at application startup or we can use that depends on where we are defining a dependency on another singleton to say that, that's singleton must be created before this singleton. The important thing is that it is available to the entire application, it is the widest application scope. Stateful session beans then maintain client-specific data often called conversational state on behalf of a client. They look like a stateless session bean, they have remote and local interfaces and they also use interceptors. Because it maintains state on behalf of a client, there is a distinct relationship between the client and the EJB instance, and that lifespans are related as well. You can pass data from a client to the instance via method parameters and store the data perhaps in class member variables. The lifetime of the bean instance is determined by the client, hence instantiation and destruction. Callbacks can be called when the client first requests and then when the client is done with the instance, hence it's an instantiation on-demand model, it is not a pooling model as we store with stateful. The lifetime of the bean instance is determined by the client, hence pooling does not occur, it is an instantiation on-demand model and is often considered far more resource intensive because of that. Below we define a stateful session EJB that's session scoped. You see the at session scoped annotation. Its lifecycle is tied to the scope of a user's session in a web container. We can see this maintaining state by simple class member variable in array of strings. We also give it a named annotation because we're going to use CDI to inject the same into perhaps a servlet. The name of the bean is the class, the lowercase letter but you can always name it something else if you want. It's only got a local interface, it's not available to remote clients. The key takeaway is, the stateful annotation and the session scoped annotation. Servlets can easily have such beans injected into them. As we saw before with CDI, we can use the at inject and we can actually use a qualify here with at inject named which you'll look for a specific bean with that name. Remember the name of the bean could be the name of the class, the lowercase first letter or if you had actually named it yourself using the at named on the class as we saw prior. Once injected in, it is session scoped the bean instance will be automatically destroyed when a session is invalidated. We can see two methods in our servlet, the one we're most interested in is the doGET method. We can see the GET session from the request and then the invalidate. If the stateful session bean employee repo is in existence, it is tied to that session and lost at that point. Once we request to another page, a new request we made from that page, as such a new instance of the stateful session bean will be created with a new list of strings, i.e with its own state. This diagram is trying to show us how this works. I'm initially on the page at the top left-hand corner of your screen, I put an employee name in and I hit the post, a new request is being made. Therefore, that requests will be associated with an HTTP session. So the session scoped bean will be created, it will then store the string, Mary contrary in its list of strings and then forward to the page or in this case it goes back to the same page. We're still in a session. So there's a new request made with Jason Ross, the session is still active, the state is still being maintained in the stateful session bean tied to that session. When we add Jason Ross to the collection, when we go and dispatch back to the page where we come, we now see the JSP displaying the entire contents of the stateful session being state or list and we see that we have two entries. If we then click invalidates session we execute on doGET method. Because we are session scoped, the session invalidation destroys the session and the associated stateful session bean instance with it and therefore it's state, Mary and Jason are lost. We then dispatch to the page again and we see that our list is empty, of course it's empty, the bean has been destroyed, it's not there. When we make a new request, a new session is created, therefore a new instance of a stateful session bean is created with its own state. When we dispatch to the page again, we see that we only have add in our state because it's a brand new session and it's a brand new instance of the stateful session bean. Our example actually touched on a couple of events in the life cycle of a stateful bean , creation and destruction. We can capture those events with callback methods within our bean. Any method marked with at post construct in the bean will be executed once the constructor and servlet injection have occurred within the EJB itself, i.e it's being created. Any method that is marked with at pre destroy will be executed when the session is being destroyed. In our case when the session became invalidated that was the end of the lifecycle. This callback method would execute. There are two other states that are called pre-passivate and post-activate. We have to explain what these are. On the right-hand side of the screen, it explains these other two callbacks. If a stateful session bean is created, being used by a client but hasn't been accessed for some time, it's said to be in an idle state and will be temporarily transformed or passivated by the container to effectively manage resources, could be some memory, etc. The transfer from it being in a ready or working state to this secondary state is called instance passivation. If a client tries to access this bean which has gone into this passive state, it is brought back into the ready state again, this is called activation and we have callback methods to mark these two events the at pre passivate and the at post activate
