[jboss-jira] [JBoss JIRA] (WFLY-2298) Redesign @Stateful EJB clustering

Redesign @Stateful EJB clustering --------------------------------- Key: WFLY-2298 URL: https://issues.jboss.org/browse/WFLY-2298 Project: WildFly Issue Type: Enhancement Components: Clustering Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 9.0.0.CR1 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.