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

[Radoslaw Rodak]

Let say 5 Node Cluster.

Simpel Case without references between SFSBs
First Cluster Member with 5 independen  SFSBs.

SFSB1 uses XPC1
SFSB2 uses XPC2
SFSB3 uses XPC3
SFSB4 uses XPC4

One remote Client connected to first Cluster Member keeping remote ref to all five SFSBs
First Node killed ( kill -9 )

If I understund Scott correctly this result in 4 LoadBalanced migration groups.
Worst Case State replicated over 4 Nodes.

Remote Client needs then 4 new remote connections....does this need more time ????

Assume now no LoadBalancing on failOver.

All SFSBs goest to let say second Cluster Member.

Remote Client needs 1 new remote connection...
Don't need to figure out any relations ( faster ) because all SFSBs and all XPCs are on same Cluster Node.

Cluster just defines which nodes replicates to which nodes. On FailOver One Cluster Member needs new Node for replication.


Am 02.12.2011 um 23:27 schrieb Brian Stansberry:

> On 12/2/11 4:22 PM, Scott Marlow wrote:
>> On 12/02/2011 04:38 PM, Jason T. Greene wrote:
>>> On 12/2/11 2:55 PM, Scott Marlow wrote:
>>>>> 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.
>>> 
>>> I still don't this is right. those references go across a proxy, and the
>>> proxy's backing data can be anywhere.
>>> 
>> 
>> I should of added that SFSB2 has a local reference to SFSB3 (which means
>> they originates on the same JVM).  I assumed that SFSB2 is migrated to
>> the same target node as SFSB3 to keep the reference local (during a
>> fail-over).  No matter, where SFSB3 goes, SFSB4 needs to be on the same
>> node (to share the same extended persistence context).
>> 
>> The SFSBs themselves, can be anywhere but the extended persistence
>> context, needs to stay with the SFSBs that inherit it.
>> 
>> Maybe there is another way to tackle this that I'm not seeing but I
>> wanted to mention these details to whomever is following this thread.
> 
> BTW, is there any spec requirement that prohibits concurrent access to 
> an XPC?
> 
> -- 
> Brian Stansberry
> Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> jboss-as7-dev mailing list
> jboss-as7-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev