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

[Scott Marlow]

More about XPC clustering below.  ;)

On 11/11/2011 10:32 PM, Scott Marlow wrote:
> 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).

The above is the application correctness issue.  If SFSB2 fails over to 
a different node than SFSB4, the extended persistence context could be 
used on two different nodes.  Basically, the extended persistence 
context can live through several non-transactional invocations.  When a 
transaction is finally started on SFSB3 or SFSB4, the XPC2 changes will 
finally be committed.

We need to have a load balancing policy that knows how to fail-over the 
beans in the serialization group, as a group.  So, that all requests to 
any of the beans, always run on the same target node (else we can have 
the same pending database changes applied from multiple nodes).

We also need the serialization group to be complete.

Scott

>
> 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
>>
>>
>
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev