What EJB version do you use 2.x or 3.x? It will help for an answer.
Best try is to avoid such 'stateful' behaviour ;-(
For our application (do not use spring) we found out that it will work without some caching more stable and without a performance drawback.
We have entities with a high change frequency and the data in cache are ruled out and must be loaded anyhow.
Solutions for you might be
- JBoss(Tree)Cache, replicate the state in the cluster (time gap possible because of async replication after commit)
- Special entity without caching or with the invalidation feature (EJB2 entities)
- your own implementation and a signal if it must be refreshed (we do this for master data via JMS)
Also you should think about the load-balancing, it is not ensured that two calls of SLSB in a sequence will reach the same JBoss instance in a cluster, this might produce problems if the cache-data will be not the same ...