Stateless Session EJB

A stateless session EJB free pool improves performance and throughput as beans are created at server startup or deployment time. WebLogic Server uses a cache of bean instances to improve the performance of stateful session EJBs. The cache stores active EJB instances in memory so that they are immediately available for client requests.
Using application-level/combined cache will result in reduced fragmentation, better utilization of memory and heap space. But the use of application-level/combined cache is limited to entity EJBs in an enterprise application. For an application that requires high throughput, use bean-level caching. Bean-level caching is effective because tasks do not compete for control of the one thread of control in a combined cache.

To make use of WebLogic provided optimization of calls made to EJB components within an application, set to true.

The same can also be achieved by writing local interfaces for EJBs for access within the same enterprise application.

Concurrency strategies for entity EJBs include:

Database:Improves throughput by deferring to database (for EJB 1.1 and 2.0, this is the default and recommended mechanism)

Exclusive:Avoids deadlocks; use it only if a high level of consistency is required on non-clustered servers

Optimistic:No lock will be held in the EJB container or database during transaction. But the EJB container ensures that the data being updated by a transaction has not been changed.

Read-only:Container does not attempt to save a bean's state at the end of a transaction; use this for EJBs that do not make any change to persistent data. With the read-only strategy, use to invalidate cached bean data in the container; this updates the data from the persistent store when a timeout occurs.

Tips

1. Consider the number of execute threads, to configure maximum number of beans in the free pool.

2. To limit the memory used by a stateful session EJB, set the maximum number of beans that can reside in the cache (max-beans-in-cache).

3. Too small cache causes frequent activation and passivation.

4. Too large a cache wastes memory.

5. LRU algorithm keeps a bean in the passive state after it passes the ideal number timeout seconds.

6. To avoid the associated overhead of passivating stateful session EJBs, use the not recently used (NRU) algorithm

7. Local interfaces for EJBs provide optimized access for server-side EJB clients.

8. Combined cache enables the administrator to tune just one cache, rather than multiple caches, in weblogic-application.xml.

9. Message-driven beans that use container-managed transactions must use XA connection factories.