"ALRubinger" wrote:
...
* Add new internal callback mechanisms for things like "prePassivate", "passivationStarted", "passivationCompleted". Part of the contract of the cache impl will be to implement these callbacks (thus allowing us to do whatever blocking/locking or get notification in tests).

"ALRubinger" wrote:
...
* WTF was I thinking with this horrid CacheFactory-per-impl design? Should better be a configurable factory capable of creating any N Caches. Ditto for the PersistenceManagerFactories. I'll have to change up the relevant jboss-beans.xml to fix this as well.

Preface: I didn't read your post in detail; gotta do other stuff right now. :-)

Comment: If you're going to make a bunch of refactorings, perhaps we should look at starting from the code in
https://www.jboss.org/community/docs/DOC-9565 which is a lot cleaner than the stuff we have today.

To clarify a bit:

First, ha-server-cache-spi and ha-server-cache-jbc have nothing to do with the ejb3 project. They define an spi for the AS project's use of JBC (e.g. web session replication), not ejb3's.

The implementations in ejb3-cache in trunk are not actually used anywhere. AFAIK, they are prototypes, and were used as the foundation for the work I did in the dev branch. (Andrew, you never said otherwise -- just stating that for clarity.)

The stuff discussed in https://www.jboss.org/community/docs/DOC-9565 is a slightly different version of the ejb3-cache SPI (contained in the "cache" module discussed on the wiki), along with a considerably different impl.

The abstractions in ejb3-cache in trunk that are used anywhere outside of ejb3-cache itself are:

Cache
Identifiable
StatefulObjectFactory

From our Neuchatel discussions, on my borderline-TODO list for AS 5.0.0.GA was to look at those interfaces and reconcile any differences to the work in the dev branch to make sure we had a clean path forward for moving to the dev branch implementation down the road. Sounds like that needs to move from "borderline-TODO" to "do it now". I'll look at it tonight. No World Series on anyway. :-)

I've analyzed the SPI differences between the cluster-dev branch and trunk's ejb3-cache:

https://www.jboss.org/community/servlet/JiveServlet/download/9565-24-5989/ejb3-trunk-vs-cluster-dev.ods

Can be summarized as:

1) Some minor stuff we just need to sort. Names, stuff missing in one or other that obviously needs to be there, etc.

2) StatefulObjectFactory.create(..) method -- cluster-dev branch's shared state map idea. I believe a version of the shared state map concept could be implemented easily enough by our existing StatefulCache impls; i.e. there is a path to compatibility.

3) Replace current call pattern of Cache.create() returns StatefulBeanContext with Cache.create() returns "id", followed by call to Cache.get("id") returns StatefulBeanContext. Shouldn't be a big deal.

4) StatefulContainer (or some delegate) implements PassivationManager. This might be a bit tricky because StatefulTreeCache currently calls some extra StatefulContainer methods that aren't in PassivationManager and aren't needed by the cluster-dev impl. So have to think a bit about that.

5) Deal with the cache factory stuff, which is somewhat orthogonal, except for the fact that a Cache has a ref to a StatefulObjectFactory and a PassivationManager, both of which are presumably implemented by the container. So if we inject the cache into the container, the container will have to pass back a ref to whatever implements those interfaces.

Sorry, Andrew, this particular post is somewhat hijacking your thread....