Bringing in ejb3-cache

[alrubinger]

Recent work in SimpleStatefulCache has uncovered a few issues:

* https://jira.jboss.org/jira/browse/EJBTHREE-1551
* https://jira.jboss.org/jira/browse/EJBTHREE-1549 (Resolved)

My tests for 1549 are imperfect as they put Thread.sleep() into the client, resulting in:

* Long execution time
* Assumption that background work will have completed in the time allotted

This has to be fixed.

The best way to do this would be to extract out portions of SimpleStatefulCache such that they may be overridden with some locking introduced (@see org.jboss.ejb3.core.test.ejbthree1549.ForcePassivationCache.BlockingPassivationTask.block()).

And while we're at it, the cache impls should really conform to the Cache SPI as dictated by the ejb3-cache project. Currently they do not.

I'm working on the following:

* Move / Copy / Something to put SimpleStatefulCache into ejb3-cache. Currently I can't have this implementation conform to both the legacy StatefulCache and new Cache SPIs because they're incompatible.

* Do the extraction and fix the tests as outlined above

* 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).

* Move StatefulContainer to the new Cache SPI

* 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.

Anything else we want to get in there?

I'm unsure of what to do with the TreeCache impl here, because the second I move StatefulContainer to rely upon the new Cache SPI, that'll break.

For now I'm starting with the elements that won't break everything. I'll have to coordinate/schedule API changes w/ Brian.

S,
ALR

[wolfc]

"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).

Wouldn't a dummy persistence manager be enough?

"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.

What I really would like to see is a deployer which takes cache metadata (@CacheConfig) and creates a cache based on that. Which we then inject into the container using @Inject with component scope.

That would require the container to be a MC component as well though. See embedded ejb deployers.

[brian.stansberry]

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.

[alrubinger]

Oh boy, so now we've got:

* The Legacy Cache stuff in EJB3 Core
* Carlo's SPI in ejb3-cache
* Brian's ha-server-cache-jbc, which implements ha-server-cache-spi, which isn't an extension of ejb3-cache...

So I need to know in which direction we're moving.

For now I'll just get enough hooks in there so I can take the Thread.sleep()s out of the tests and resolve EJBTHREE-1551.

S,
ALR

[brian.stansberry]

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. :-)

[alrubinger]

"bstansberry" wrote:
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.

Ah, sorry for the confusion. I'd thought this replaced the "cluster-dev" branch noted by the Wiki, which Brian now points out is "jbossas/projects/ejb3/branches/cluster-dev/".

I'll take some time to look at this to see the differences between here and the prototype work in ejb3-cache. From speaking with Carlo I'd understood ejb3-cache to be a potential implementation (which we're not using yet in EJB3 Core).

S,
ALR

[brian.stansberry]

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....

[alrubinger]

First of all, in the time it took me to read a couple chapters of Bloch, Stansberry did all this. :)

I don't want to step on toes, so I've committed the changes to SimpleStatefulCache directly without bringing it into ejb3-cache and out of Core. It's testable enough for now.

To revisit in greater depth tomorrow.

S,
ALR