[jboss-as7-dev] EJB passivation/activation, clustering and JPA extended persistence context handling...

[Scott Marlow]

A related question, I'm trying to get up to speed on what internal state 
needs to be replicated, for SFSBs that reference extended persistence 
context.  This will help me review some clustering code that is coming 
together in this area.  I think we need to replicate the following but 
want to see what else needs to be covered:

- The stateful session bean attributes as represented by the EJB container.

- The extended persistence context as represented by the JPA 
container/subsystem.

- The JPA SFSBXPCMap which can map a SFSB to collection of extended 
persistence contexts that directly referenced.  Can also map a extended 
persistence context to collection of SFSBs that reference it.

- The JPA interceptors associated with each stateful session bean, need 
to be ready to fire after fail-over has occurred (e.g. 
SFSBDestroyInterceptor needs to fire when SFSB @Destroy is invoked after 
a fail-over).

- Are there other interceptors associated with the SFSB that also need 
to be replicated?

- Any other state for stateful session beans that is held externally to 
the SFSB instance?

- Which SFSB classes are to be replicated with the SFSB?  The 
StatefulSessionComponentInstance?

We also know that we need to replicate the serialization group (as its 
definition changes dynamically).  For example, the application has five 
stateful session beans (SFSB1-SFSB5) that are associated with three 
extended persistence contexts (XPC1-XPC3).  The relationships between 
these five beans are as follows:

   SFSB1 uses XPC1
   SFSB2 uses XPC1 and has reference to SFSB3
   SFSB3 uses XPC2
   SFSB4 uses XPC2 and has reference to SFSB5
   SFSB5 uses XPC3

When SFSB1 fails over, we need to fail-over its working set (the 
serialization group which includes SFSB1, SFSB2, SFSB3, SFSB4, SFSB5, 
XPC1, XPC2, XPC3).  In case its not obvious why, SFSB2 may have pending 
database updates in XPC1, so it must fail-over also to the same target 
node.  Since SFSB2 has a reference to SFSB3, SFSB3 needs to fail-over 
together with the group also (and so the pattern continues for SFSB4, 
SFSB5, XPC3).

Thanks for any answers, this will help me review the clustering code 
like I said and also think about ways to support the extended 
persistence context replication.  These are some of the questions that I 
am asking myself but wanted to open the process up for input from others 
that probably know better. ;)

Scott

On 10/24/2011 10:47 AM, Brian Stansberry wrote:
> Throwing NotSerializableException instead of serializing means removing
> support for clustering SFSBs with an XPC. That IMHO would be a pretty
> major feature regression. I believe we have supported that since AS 4.2
> if not earlier.
>
> On 10/24/11 9:39 AM, Scott Marlow wrote:
>> Hi,
>>
>> I'm looking into handling serialization of the extended persistence
>> context (for both clustering and EJB3.1 passivation/activation).
>>
>> The (JPA subsystem) spi is still developing for this but if anyone has
>> feedback or wants to follow.  A sketch for the spi is at
>> https://github.com/scottmarlow/jboss-as/blob/d7ec51ac14afb47ced7d203f8b3696c10221e9db/jpa/spi/src/main/java/org/jboss/as/jpa/spi/XPCSerializationController.java
>>
>> One question that comes up is why.  Why not just throw
>> NotSerializableException instead of serializing the extended persistence
>> context.  If anyone feels strongly that we should throw
>> NotSerializableException instead of serializing the extended persistence
>> context, I'd like to hear why.
>>
>> I've made internal changes on
>> https://github.com/scottmarlow/jboss-as/tree/cluster1 to support
>> clustering extended persistence contexts.  Next is to do the actual
>> serialization.
>>
>> Scott
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
>