EJB3 Caching Instance Variables

Question

Hi,

I've noticed some strange code on a project I am working on - its a SLSB EJB3, and it uses a private instance variable to maintain a cache of data (it even calls it dataCache or something), with a getter/setter. For EJB2 and bellow, this was a typical EJB antipattern - SLSBs are not meant to retain state in between invocations, theres no guarantee you'll see the same data on a subsequent invocation. One of my colleagues said maybe its ok in EJB3 (we don't have much EJB3 experience), but still, its a Stateless Session Bean - why is it trying to maintain state, this doesn't make sense.

Can anyone confirm if this is still a bad idea in EJB3 land, or if somehow it is ok?

Thanks if you can help, Justin

Answer 1

For EJB2 and bellow, this was a typical EJB antipattern - SLSBs are not meant to retain state in between invocations, there's no guarantee you'll see the same data on a subsequent invocation.

This is true and this is somehow a smell (because often wrongly used: people tend to forget that there is no guarantee to get the same instance, that the container could remove some bean from the pool to free resources, that beans could be distributed across JVMs, etc).

One of my colleagues said maybe its OK in EJB3 (we don't have much EJB3 experience), but still, its a Stateless Session Bean - why is it trying to maintain state, this doesn't make sense.

What was true with Stateless Session Beans (SLSB) in EJB 2.x is still true with EJB 3.0, SLSB are still SLSB, EJB 3.0 didn't redefine statelessness.

But if you use an instance variable to hold some read-only resource that is expensive to load (and make sure to load it if null), it should be ok.

Related questions

• Stateless and Stateful Enterprise Java Beans
• Stateless session bean with instance variables
• Static vs Instance members in Stateless EJBs
• Why stateless session beans are single threaded?