EJB3 SFSB passivation and replication

[ben.wang]

I have chatted with Bill Decoste on this specific issue and am raising it here for further discussion.

Currently, for ejb3 SFSB passivation and replication, we serialize the StatefulBeanContext that besides the user bean instance also comprises of ejb3 Interceptors and extended persistence contexts. Plus other items like: id, metadata, container name. Finally, it also serializes netsted sfsb references.

Now, there maybe reasons that I fail to grasp that leads to this implementatoin. But upon closer look, except the nested sfsb references, all other items should be static, IMO. That is, they can be re-created upon bean activation or replication failover.

At any rate, we currently do a re-injection of all the bean dependency upon activation. So all the resources (em, etc.) will be re-injected (except perhaps ref-env items) anyway.

Therefore, I am proposing to refactor the sfsb code as follows (this is just rough details). We won't externalize the whole StatefulSessionContext. Instead, we will externalize two separate items:

1. A SerializedStatefulMetaData object that comprises of: id, nested sfsb references, (and any future extension).

2. The user bean instance that uses id for key.

Upon activation or replication failover, we will create StatefulBeanContext first. Then we call out the handler to initialize using SerializedStatefulMetaData and the bean instance. If there are nested bean found in the SerializedStatefulMetaData, e.g., we will inject the corresponding nested bean instance as well.

With this, then I think we have:

1. reduction the serialization payload. We don't need to serialize the interceptors and extended persistence contexts.

2. transparency and consistency for both activation and replication.

3. Replication using JBossCache can then be free to implement different replication granuliarity like SESSION and FIELD in a pluggable fashion.

Any comments?

[bill.burke]

I have chatted with Bill Decoste on this specific issue and am raising it here for further discussion.

Currently, for ejb3 SFSB passivation and replication, we serialize the StatefulBeanContext that besides the user bean instance also comprises of ejb3 Interceptors and extended persistence contexts. Plus other items like: id, metadata, container name. Finally, it also serializes netsted sfsb references.

Now, there maybe reasons that I fail to grasp that leads to this implementatoin. But upon closer look, except the nested sfsb references, all other items should be static, IMO. That is, they can be re-created upon bean activation or replication failover.

Interceptor instances have the same lifecycle as the SFSB instance they intercept. 1 intercepotr instance per SFSB instance, get me?

At any rate, we currently do a re-injection of all the bean dependency upon activation. So all the resources (em, etc.) will be re-injected (except perhaps ref-env items) anyway.

That's not what I remember. We do not do re-injection I thought, but serialize the injected items.

Therefore, I am proposing to refactor the sfsb code as follows (this is just rough details). We won't externalize the whole StatefulSessionContext. Instead, we will externalize two separate items:

1. A SerializedStatefulMetaData object that comprises of: id, nested sfsb references, (and any future extension).

2. The user bean instance that uses id for key.

Upon activation or replication failover, we will create StatefulBeanContext first. Then we call out the handler to initialize using SerializedStatefulMetaData and the bean instance. If there are nested bean found in the SerializedStatefulMetaData, e.g., we will inject the corresponding nested bean instance as well.

With this, then I think we have:

1. reduction the serialization payload. We don't need to serialize the interceptors and extended persistence contexts.

2. transparency and consistency for both activation and replication.

3. Replication using JBossCache can then be free to implement different replication granuliarity like SESSION and FIELD in a pluggable fashion.

Any comments?

I had to do some very tricky and "clever" things to get nested SFSBs to work. What I would prefer is that you first abstract out the current implementation and make the mechanism pluggable. I don't want to be dependent on whether Ben Wang has fully completed this refactoring if I have to do another EJB3 release in the near future. I had this issue with your work the last release ben. I spent a good day on trying to figure out why the SFSB tests in HEAD were failing to learn that it wasn't complete. I like to work solely off of CVS HEAD so that the backmerge to the stable Branch_4_0 is simpler.

I also wish you would first finish the new SFSB replication implementation before refactoring this code base.

Bill

[ben.wang]

Interceptor instances have the same lifecycle as the SFSB instance they intercept. 1 intercepotr instance per SFSB instance, get me?

Sure. But this has nothing to do with serialization vs. re-injection, correct? The bean (and interceptor) lifecycle of interest to either passivation or replication is METHOD_READY and PASIVATED states. So I think during these states, re-injection should be ok?

That's not what I remember. We do not do re-injection I thought, but serialize the injected items.

AFAIK, Bill D. had to fix a bug in activation so now it is re-injected. Maybe he can comment it in more detailed.

As for serialization vs. re-injection, I think cost should be not much different in the passivation case because passivation should not happen that often anyway.

As for replication, re-injection will actually have advantages because failover is even rarer. So we save the cost of serialization of the extra payload for each replication.

I had to do some very tricky and "clever" things to get nested SFSBs to work.

Yes, I have noticed that. And this is what I have been trying to figure out. :-) If re-injection will work, it should simplify the way that nested SFSB is being passivated, isn't it? Or do you remember any deeper reason to that?

Furthermore, if the nested SFSBs parts are not static, then the new fine-grained implementation won't have any real advatange since it will need to replicate the whole StateulBeanContext for every bean modification. For now, I am not seeing that to be true though.

What I would prefer is that you first abstract out the current implementation and make the mechanism pluggable. I don't want to be dependent on whether Ben Wang has fully completed this refactoring if I have to do another EJB3 release in the near future. I had this issue with your work the last release ben. I spent a good day on trying to figure out why the SFSB tests in HEAD were failing to learn that it wasn't complete. I like to work solely off of CVS HEAD so that the backmerge to the stable Branch_4_0 is simpler.

I also wish you would first finish the new SFSB replication implementation before refactoring this code base.

Exactly, I will refactor the current implementation and make it pluaggable such that the new code won't be in your way.

The previous refactoring was not for the new sfsb implementation. But rather just for the passivation part. Unfortunately, I have to wait for a new JBossCache release as we have discussed it before.

[ben.wang]

We have had a meeting in Vegas to discuss this further. It is more complicated than we thought to simply re-inject the Hibernate ExtendedPersistenceContext.

We also had a conf call on Wednesday to discuss this further on how to move forward on possibly for Hibernate to provide some sort of API to manage the replication delta (and more).

For more details, I have update the Jira:
http://jira.jboss.com/jira/browse/EJBTHREE-585 and this wiki:
http://wiki.jboss.org/wiki/Wiki.jsp?page=Ejb3ClusteringAndExtendedEntityManager