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

[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