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

[Paul Ferraro (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-2298:
-------------------------------

    Description: 
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 required to lock 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
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
	* If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
	* If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

  was:
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 required to lock 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
* The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
* State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
* The @Clustered annotation currently has 2 orthogonal meanings:
    * If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
    * If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.


    
> 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 required to lock 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
> * The lifecycle of the global group cache is not correctly handled by the MSC and is prone to race conditions
> * State changes that occur to the SFSB during activation/passivation callbacks are not correctly replicated.
> * The @Clustered annotation currently has 2 orthogonal meanings:
> 	* If applied to a @Stateful EJB, then a specific cache will be used (as defined by the EJB subsystem)
> 	* If applied to a @Stateless or @Stateful EJB, remote EJB clients will have a dynamic view of the EJB's topology.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira