DIFFERENCE BETWEEN SESSION BEANS AND ENTITY BEANS

DIFFERENCE BETWEEN SESSION BEANS AND ENTITY BEANS

To understand whether a business process or business entity should be implemented as a

stateful session bean or an entity bean, it is important to understand the life-cycle and

programming differences between them. These differences pertain principally to object

sharing, object state, transactions, and container failure and object recovery.

Object sharing pertains to entity objects. Only a single client can use a stateful session

bean, but multiple clients can share an entity object among themselves.

The container typically maintains a stateful session bean's object state in the main

memory, even across transactions, although the container may swap that state to

secondary storage when deactivating the session bean. The object state of an entity bean is

typically maintained in a database, although the container may cache the state in memory

during a transaction or even across transactions. Other, possibly non-EJB-based, programs
can access the state of an entity object that is externalised in the database. For example, a
program can run an SQL query directly against the database storing the state of entity
objects. In contrast, the state of a stateful session object is accessible only to the session
object itself and the container.
 

The state of an entity object typically changes from within a transaction. Sinces, its state
changes transactionally, the container can recover the state of an entity bean should the
transaction fail. The container does not maintain the state of a session object
transactionally. However, the bean developer may instruct the container to notify the
stateful session objects of the transaction boundaries and transaction outcome. These
notifications allow the session bean developer to synchronise manually the session
object's state with the transactions. For example, the stateful session bean object that
caches changed data in its instance variables may use the notification to write the cached

data to a database before the transaction manager commits the transaction

 Session objects are not recoverable; that is, they are not guaranteed to survive a container
failure and restart. If, a client has held a reference to a session object, that reference
becomes invalid after a container failure. (Some containers implement session beans as
recoverable objects, but this is not an EJB specification requirement.) An entity object, on
the other hand, survives a failure and restart of its container. If, a client holds a reference
to the entity object prior to the container failure, the client can continue to use this
reference after the container restarts.
The Table 1 depicts the significant differences in the life cycles of a stateful session bean
and an entity bean.