-
These are generally tied to the lifetime of a given client session.
-
They are relatively short-lived.
-
The stateful session objects are created in response to a single client’s request, communicate exclusively with a single client and die when the client no longer needs them.
-
A session bean is required to implement the javax.ejb.SessionBean interface.
public interface javax.ejb.SessionBean extends javax.ejb.EnterpriseBean
{
public abstract void ejbActivate();
public abstract void ejbPassivate();
public abstract void ejbRemove();
public abstract void setSessionContext(SessionContext ctx);
}
-
Al of the methods declared in this interface are callback methods; that is they are invoked by the container to notify the Session EJB that some event has occurred.
ejbPassivate()
-
Container calls this method to swap the EJB class out to “semi-persistent” storage.
-
The storage is “semi-persistent” because Session EJBs do not carry the same sort of guarantee of long life as Entity EJBs do.
-
If the EJB container crashes or restarts, the session beans that existed before the crash or restart are destroyed.
-
Session bean also have an associated timeout value; after the timeout expires, they are destroyed.
-
If none of these events happens the session bean can be sapped back in at some later time.
ejbActivate()
-
The ejbActivate() method is essentially the inverse of the ejbPassivate() call.
-
The container calls this method after a session bean’s state has been restored from “semi-persistent” storage, but before it becomes available to the outside world.
-
A bean can use the ejbActivate() call to restore any resources that is closed before being passivated.
ejbRemove()
-
This callback method in invoked by the container as a result of a client calling the remove() method of a bean’s home or remote interface.
-
The client’s invocation of the remove() method notifies the container that this particular session bean instance should be destroyed.
setSessionContext(SessionContext ctx)
-
This method is called at the very beginning of a session bean’s life.
-
The container passes the session bean an object that implements the SessionContext interface.
-
The bean stores this object in an object variable, and can then use the SessionContext to interact with container-provided services such as security and transaction management.
The EJBContext Interface
-
The SessionContext interface inherits from the EJBContext interface.
-
The EJBContext interface is the parent interface of both the SessionContext and EntityContext interfaces.
public interface javax.ejb.EJBContext
{
public abstract Identity getCallerIdentity();
public abstract EJBHome getEJBHome();
public abstract Properties getEnvironment();
public abstract boolean getRollbackOnly();
public abstract UserTransaction getUserTransaction();
public abstract boolean isCallerInRole(Identity role);
public abstract void setRollbackOnly();
}
getCallerIdentity()
-
This method is used to get a java.security.Identity object that represents the identity of the client.
-
It can be used in concert with isCallerInRole() to allow the EJB object to perform authorization checks before performing an operation.
getEJBHome()
-
This method is used to get a reference to its own home interface.
-
This interface can be used to create or find other instances of the bean class, or to do several other things.
getEnvironment()
getRollbackOnly()
-
EJB supports distributed transactions.
-
If any of the players in a distributed transaction cannot continue for some reason, it can mark the transaction as “rollback only”.
-
A “rollback only” transaction can never complete; it must be rolled back.
-
A bean can use this to check the status of a transaction before attempting to participate in it.
getUserTransaction()
-
In TX_BEAN_MANAGED transaction type, the bean is responsible for beginning, committing and possibly rolling back its own transactions.
-
If a bean has a transaction attribute of TX_BEAN_MANAGED, it can use getUserTransaction() to gain access to the transaction.
The UserTransaction Interface
public interface javax.jtx.UserTransaction
{ public final static int STATUS_ACTIVE;
public final static int STATUS_COMMITTED;
public final static int STATUS_COMMITTING;
public final static int STATUS_MARKED_ROLLBACK;
public final static int STATUS_NO_TRANSACTION;
public final static int STATUS_PREPARING;
public final static int STATUS_PREPARED;
public final static int STATUS_ROLLEDBACK;
public final static int STATUS_ROLLING_BACK;
public final static int STATUS_UNKNOWN;
public abstract void begin();
public abstract void commit();
public abstract int getStatus();
public abstract void rollback();
public abstract void setRollbackOnly();
public abstract void setTransactionTimeout(int seconds);
}
-
This provides the classic “begin”, “commit”, and “rollback” operations
-
getStatus() operation, which allows the caller to see the status of the transaction.
-
Also allows the caller to set a transaction timeout, enabling the caller to set some upper bound on the execution time of the transaction.
isCallerInRole()
setRollbackOnly()
The SessionContext Interface
public interface javax.ejb.SessionContext extends javax.ejb.EJBContext
{
public abstract EJBObject getEJBObject();
}
-
This contains only one method namely getEJBObject().
-
This method returns a reference to an EJBObject.
-
This remote reference to an object implements the bean’s remote interface, and can be used if the bean wants to pass a reference to itself to some other entity.
-
EJB Container is responsible for creating objects that implement the remote interface; these objects act as proxies, forwarding the business method calls to the object.
-
Session bean’s home interface provides one or more “create” methods.
-
“create” methods are invoked by clients to create new instances of a particular EJB object.
-
When a client invokes a create() method on the bean’s home interface, the container creates an object of the appropriate type, calls its setSessionContext() method, and then calls a method in EJB class called ejbCreate().
The Rules for an ejbCreate() method in Session Beans are as follows:
-
The method must have a void return type. The container will pass the remote interface back to the client.
-
The number and type of arguments to the ejbCreate() method must exactly match the number and type of arguments in the corresponding create() method declared in the home interface.
The following steps are involved in the creation of a new Session Bean:
-
The client calls a create() method in the bean’s home interface.
-
The container sets aside storage for the object and instantiates it.
-
The container calls the object’s setSessionContext() method.
-
The container calls the ejbCreate() method whose signature matches the create() method invoked by the client.
Stateful and Stateless Session Beans
-
A stateless session bean is one that doesn’t keep track of any information from one method call to another – essentially, a bean with no instance variables. (Ex: CalculateInterest Bean)
-
Any two instances of a stateless bean are equivalent.
-
A container can easily handle a stateless Session bean, because instances of a stateless bean can be created and destroyed at will, without worrying about their state at the time of their destruction.
-
A stateful session bean, is a bean that changes state during a conversation – that is, a bean that has instance variables. (Ex: Shopping Cart Bean)
-
The life cycle of a stateful bean is more complex for the container than the stateless bean.
-
Because, the container have to maintain the state of the stateful session bean during swap out and swap in process.
-
According to the EJB specification, EJB Objects are not allowed to have static variables.
The SessionSynchronization Interface
public interface javax.ejb.SessionSynchronization
{
public abstract void afterBegin();
public abstract void afterCompletion(boolean committed);
public abstract void beforeCompletion();
}
-
A session bean can implement the SessionSynchronization interface if it wishes to be notified by the container about the state of any transaction in which it may be involved.
-
Even if a Session bean does not manage its own transactions via the UserTransaction interface, it may still implement the SessionSynchronization interface.
-
All of the methods in the SessionSynchronization interface are callbacks.
afterBegin()
beforeCompletion()
-
This method indicates that a transaction is nearly complete.
-
If the bean wishes to roll back the transaction for some reason, it can call the setRollbackOnly() method of the SessionContext interface to do so.
afterCompletion()
-
The container calls this method after a transaction has been completed.
-
Its boolean argument will be set to true if the transaction was committed successfully, and false if the transaction was rolled back.
-
This interface must be implemented in the stateful session bean because, the state of instance variables is not transactional.
-
That is, if the instance variables in a session bean are modified during the course of a transaction and the transaction is then rolled back, the instance variables will not be automatically reset to their original state prior to the transaction.
-
To reset the instance variables, the SessionSynchronization interface is needed and use the afterCompletion() callback to read the state variables back out of the database.
-
Note that, a stateless session bean cannot implement this interface, because, it has no state, there’s no point in trying to synchronize its state with the database.
|
