Pooled EJB versus Shared Instance POJO

Good to know when someone says we need to use SSB's for performance reasons.

--------------------------------------

From the book "J2EE without EJB" . This blog has a good summary.

http://forum.springframework.org/archive/index.php/t-23787.html

From the above post:

Rod Johnson 04-07-2006, 05:35 AM

I'm just wondering if there might be a performance benefit with the instance pooling provided with a stateless ejb implementation, vs. having a singleton object. Any insight there?
Ok, I can't resist.

The benchmarks published in J2EE without EJB were the result of prolonged load testing against the leading commercial and open source app servers, on production-quality hardware. The results showed that
- Singleton with Spring-managed transactions dramatically outperformed local or co-located remote EJBs in the open source application server (by 1.5 to 3x, even when many calls resulted in database hits), and consistently (but marginally) outperformed SLSBs in the commercial application server.
- Average response time was distinctly better with the Spring-managed singleton
- The spread in response times was much narrower in the Spring-managed singleton approach (good).

Pooling is greatly overrated for SLSBs. It is actually a flaw in the EJB spec (all versions) that pooling is effectively required, even for local EJBs, when thread pooling can be performed by the web container. Most stateless objects are naturally threadsafe. Thus they gain nothing from pooling.

There is no way in which a pool can outperform a shared instance if there is no need for synchronization on the shared instance.