adam bien's blog

The performance of stateful session bean was always great... 📎

I tested some years ago the performance of SFSB with J2EE 1.3 RI, WLS 6.X and JBoss 3.X. The funny thing was: SFSB sometimes outperformed the SLSB. The application server tries to optimize the usage of SLSB instances and searches first for free beans in the pool, afterwards either waits until a "in-use" instance will be returned to the pool or creates a new one. There is no such optimization for SFSB so, the application server simply routes all requests to the same instance which is sometimes faster, than the SLSB approach.
I did these measurements, becauso of strange policies in a large scale project. The chief architect liked the stateless architecture very much and prohibit the usage of SFSB. ...but the developers needed the state and built a singleton which maintained the state of SLSB. A session id was passed between client and server -> so they built SFSB with SLSB and a singleton, which led to memory leaks :-).

The performance of SFSB was always great. The one and only possible issue is the replication in cluster (which is not needed, because SFSB are transient and the state is not transactional per definition). So if you have to maintain state SFSB or HTTPSession (jboss replicates both with the same technology) are great. The state of the business logic should be maintained using the SFSB, and the state of the presentation logic in HTTPSession.

The two stage passivation and long sessions could be a real issue for heavy loaded applications, but this is a general topic and mostly Java EE independent.

Btw. I do not expect differences in the performance of SFSB between the J2EE 1.3/1.4, Java EE 5 specifications, but there can be differences between the implementations of different application servers.

Premature Optimization Is The Root Of All Evil :-).

---Advert----
I described also the issues with state in my last (but german :-)) book.