martedì 18 giugno 2013

EJB 3 lifecycle

Today we will see how stateful and stateless bean does live their life, thus this will be used in another article in order to do a tricky session managment.

The lifecycle

We must distinguish between stateless session bean and stateful session bean because their lifecycle is different.

Before describing the difference in the lifecycle, let's recall the diffrerences between stateful and stateless:


  • Stateful
    they use class variables that are kept across the "conversation" between client and server (bean).
    Thus is possible to declare global variable in the class that implements the EJB, and theese variables are hold among the different requests of the client.
    When the client terminates there are two options to be undertaken: the bean is removed or session ends, thus state disappears.

    This kind of EJB are less scalable, wtr to the stateless. This is due to the overhead introduced by the need to keep the conversational state (memory on server side, methods called to maintain the EJB...).


  • Stateless
    They do not use class variables,  it will be useless because they die after the method call.

    They are throwaway enterprise beans. Thus by this feature their usage result in a more easy scalable application building. This type of beans can serve different clients at the same moment, without keeping track the about the session management. Hence there is no overhead for the server which is less stressed by the usage of this type of beans.

Let's take a look at the lifecycle now. Let's start by the latest one described above.


Stateless bean lifecycle
  • Stateless


    Stateless'bean lifecycle is described by the image here on the side.
    Very simply: 2 states for this state machine. The bean does not exist when is waiting to be called by the client. Once upon the bean is called it goes to the state ready. During this phase/state the bean can compute and perform the operation requested by the client through the remote method invocation. Hence once the method is terminated the bean goes back to does not exists.
    We can notice that there are:
    1. NO PASSIVATION
    2. NO ACTIVATION
Stateful bean lifecycle
  • Stateful

    Stateful beans add more than what the stateless offers. The basic concept remains the same.
    There are the does not exist state and the ready state, but further there is a state which is passive.
    This state is coming out from the need of maintaing the session, thus the variables. Once up on the bean is created is not destroyed when the first method invocation finishes, but is remains ready to satisfy other client requests. Anyhow the memory of the server may be used by other beans, or in general by other tasks, thus the bean is passivated and removed by the memory. From the oracle docs we can read "(Typically, the EJB container uses a least-recently-used algorithm to select a bean for passivation.) ".
    We can notice the need of:
    1. PASSIVATION. Used to move from the primary memory (ram probably) to a secondary memory on the server (cache, hard disk, raw memory)
    2. ACTIVATION. Used to bring back from secondary memory the bean, thus placing it in the primary memory ready to be called and serve the client.

Note that every step may be controlled through the annotation, we may for example want to run a task upon the Passivation or Activation of the bean, as well as when is Created or Removed.

We will see how to do a tricky session management with a stateful session bean in another article.



Sources:

Roseinda EJB tutotial session bean
docs oracle
image sources
roseinda
docs oracle