The current @Stateful EJB clustering design has a number of flaws:
- The current implementation is very slow. Each EJB invocation results in 4 Infinispan transactions! Cache.get(...) and Cache.release(...) result in 2 transactions each, 1 for bean cache and 1 for group cache
- An external locking mechanism is used to guard the SFSB against access from other nodes between Cache.get(...) and Cache.release(...)
- Because the current design uses 2 separate cache instances, data is not correctly isolated and can cause integrity issues
- The current design uses a global group cache, which results in classloader leaks when a server has multiple EJB deployments (MarshalledValues in the group cache, which survives undeployment, can still reference the classloader of an undeployed EJB)
- The lifecycle of the global group cache does not leverage the MSC and thus is prone to race conditions by multiple SFSB deployments
- State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
- The @Clustered annotation currently has 2 orthogonal meanings:
1. If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
2. If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.
- Eager passivation is unnecessarily expensive, and makes the eventual SFSB removal slower.