Wrap Entity Beans with Session Beans
- Session Facade Pattern
Session-Entity facade pattern recommends wrapping an entity
bean with a session bean. Accessing an entity bean across the network using
RMI-IIOP results in severe performance loss. This pattern optimizes the system
by executing complex use cases in a single network call and also enforces a
clear and strict separation of business logic from presentation and data logic.
Allowing the clients to access an entity bean directly,
requires the client to have knowledge about entity bean implementation, which
is not desirable. However this assumes that all requests will need ALL of the
data in the EJB, resulting in returning unnecessary data to the user, and incurring
additional overhead of marshaling and unmarshalling the larger value objects.
Stateful Vs Stateless Session Bean
EJB containers pools stateless session beans and reuses them
to service many clients. Stateful session beans can be passivated and reused
for other clients. But this involves I/O bottlenecks. Because a stateful session
bean caches client conversation in memory, a bean failure may result in loosing
the entire client conversation. Therefore, while writing a stateful session
bean the bean developer has to keep the bean failure and client conversation
loss in mind.
In case of stateless session beans, client specific data has
to be pushed to the bean for each method invocation which will result in increase
in the network traffic. This can be avoided in a number of ways like persisting
the client specific data in database or in JNDI. But this also results in I/O
performance bottlenecks.
If the business process spans multiple invocations thereby
requiring a conversation then stateful session bean will be the ideal choice.
On the other hand, if business process lasts only for a single method call,
stateless session bean model suits.
State
Maintenance - Stateful sesson beans Vs Http Session
There are different type of clients accessing an EJB in a
J2EE application. One of the main requirements in a typical J2EE application
is the successful maintenance of the client identity/state. Session maintenance
can be achieved in multiple ways. The question that arises here is when to use
stateful session bean for session maintenance and when to use Servlet HTTP session?
Stateful session beans should be used when the EJB application is also accessed
by an application client which does not use HTTP. Servlet HTTP session will
be the most suitable choice if the clients talk to the EJB application via HTTP.
Entity Bean Performance Tuning
Where ever possible, using Entity bean with CMP over Entity
bean with BMP, will ensure increase in performance.
In case of BMP, usage of lazy loading techniques to load
the required fields instead of loading all the fields should improve performance.
Usage of Value-Object design pattern (dependent objects)
in entity beans, reduces network traffic thereby increasing performance.
In BMP, usage of a boolean flag to control call in ejbStore
method reduces unnecessary round trips to the database. Whenever the entity
bean field value changes, the boolean flag can be set to true. Depending on
the value of the flag, the persistence logic should be coded. For sample ejbStore
with boolean flag click here.
Depending upon the requirement of the application, Coarse
grained entity beans that represents more than one table or fine grained entity
beans that represents a single table can be used. Using
coarse grained entity bean decreases the number of network calls.
Container Managed Vs Bean Managed
Persistence
Tuned CMP entity beans offer better performance than BMP entity
beans. Moving towards the CMP based approach provides database independence
since it does not contain any database storage APIs within it. Since the container
performs database operations on behalf of the CMP entity bean, they are harder
to debug. BMP beans offers more control and flexibility that CMP beans.
BMT Vs CMT
For specifying transaction boundaries for components, XML
deployment descriptors are used. At runtime, the container initiates a transaction
and commits it. This helps the user in avoiding the transaction related code
within the bean and helps in focusing on the core business logic of the application.
In this approach, the EJB code is completely isolated from the transaction APIs.
CMP entity bean has to use CMT for transaction purposes. For sample deployment
descriptor code snippet click here.
In Bean managed programmatic transactions, bean developer
has to control the transaction boundaries explicitly. The benefit of this approach
is that the bean developer has full control over the transactional boundaries.
The developer has to start a transaction by issuing a begin and complete the
transaction by issuing an end or abort statement. Bean managed Transaction can
be used only for Session Beans. For sample code snippet click here.
Bookmark