JBossDeveloper

"wolfc" wrote:
Two things:
1. The life cycle of all SFSB using that XPC are connected. Maybe we can limit that to just the passivation/activation.
2. Partial replication should be possible.

To document our chat:

In 4.2 it works like this:

BeanA is the parent of a nested SFSB hierarchy. It holds a ref to the BeanB SBC (and to the XPC). The "one serialized unit" you mention is passivated under BeanA.id.

When BeanB is passivated, what gets written to disk under BeanB.id is a ProxiedStatefulBeanContext; a proxy. If the user activates BeanB, the ProxiedStatefulBeanContext is activated and knows how to find BeanA's cache, find the BeanA SBC in that cache, and find the real BeanB SBC inside the BeanA SBC. The ProxiedStatefulBeanContext then delegates all calls to the real BeanB SBC.

I just posted some prototype stuff related to getting Carlo's stuff to work well with clustering at https://svn.jboss.org/repos/jbossas/projects/ejb3/branches/cluster-dev/ejb3-cache

Carlo, here are some key points:

1) Cache has a couple methods added re: clustering support that we discussed this am. I made no changes yet based on our discussion.

2) PassivationManager has methods for replication callbacks.

3) PassivationGroup et al renamed SerializationGroup, since it's for both passivation and replication.

4) SerializationGroup has pretty significant API changes, mostly related to exposing stuff from the impl. I needed this so I could use the impl in my cache versions (see #6 below) without breaking your cache versions.

5) IdentityObjectStore. This is the key thing. Your SimplePassivatingCacheImpl has a hash map for an in-memory store, and then an inject edObjectStore for persistence. JBoss Cache combines the in-memory and persistent store. I need an abstraction that can handle that; this interface is that abstraction. SimpleIntegratedObjectStore is an impl of the interface that is suitable for use in a non-clustered cache. The o.j.e.test.distributed.MockJBCIntegratedObjectStore is a mock impl that behaves the way an interface to JBC would.

6) SimplePassivatingCache2/GroupedPassivatingCacheImpl2. Analogues to your classes, but using IntegratedObjectStore instead of ObjectStore. I tried to change your classes as little as possible.

7) New Cacheable interface. Exposes the inUse and lastUsed properties. Trying to get an analogue to your SimplePassivatingCache.Entry to work with the IntegratedObjectStore was proving to be a bridge too far. So I assumed the StatefulBeanContext would expose the Cacheable interface, allowing me to get rid of the need for a wrapper object like SimplePassivatingCache.Entry. SBC exposes the methods now and I assumed they were needed. We we're IMing today about the general "inUse" question, so that discussion impacts this.

8) Tests. Non-existent right now; hope to do at least a basic one this PM. Your tests still pass though.

Crap; hoist by my genericized-petard. :( Once I try to actually create a GroupedPassivatingCacheImpl2 in a test, I hit a generics wall. :(

OK, that's sorted.

One other point on what I did in this branch:

The main reason the SimplePassivatingCache.Entry concept from trunk doesn't work is that object needs to be replicated. Without it after failover other nodes in the cluster wouldn't be able to find the group.

This got put on the back burner for AS 5 beta3 as it wasn't an API issue. Then again pre-JBW as EJB3 was being broken apart and seemed unusable. I've been back at it these last few weeks. Please see http://wiki.jboss.org/wiki/Wiki.jsp?page=DevEJB3NewSFSBCache for current status.

Carlo, need your input on the 2 "Major Unresolved Issues" discussed on the wiki page.