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

[Scott Marlow]

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.