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.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat