On 11/21/2011 03:50 PM, David M. Lloyd wrote:
On 11/21/2011 02:40 PM, Scott Marlow wrote:
>>
>> Summary
>> -------
>>
>> For both options, we have to determine an appropriate load-balancing
>> strategy. The choice of direction will affect how our clustering and
>> transaction interceptors function. We also have to suss out the logic
>> around dealing with conflicting or wrongly-ordered topology updates;
>> hopefully our existing policies will continue to apply.
>>
>
> I just wanted to mention, that when we talk about load-balancing
> strategies/policies, that we might need some strategies that can handle
> affinity for groups derived from extended persistence. In other words,
> this would be a policy that understands how to migrate a group of
> stateful session beans to the same target node, during fail-over.
>
> A simple example would be for two stateful session beans (SFSB1 +
> SFSB2), that share an extended persistence context (XPC1). When an
> instance of SFSB1 fails-over to a new cluster node, the corresponding
> SFSB2 instance should fail-over to the same target node.
>
> Another example, would be the same as above, except SFSB2 has a
> reference to SFSB3, which has a different XPC3. XPC3 is also used by
> SFSB4. So, the load balancing policy would be need to have some
> heuristic or maybe group-id that covers this case.
>
> One reason for ensuring that the same node is chosen for groups derived
> from use of extended persistence context, is so that applications can
> continue to see dirty data that is associated with the XPC.
I'm going to move this out of the "clustered invocation" column and into
the "stateful session replication" category which is, to my
understanding, Paul's purview at the moment.
Just to keep everything in the open, I think when we do cluster extended
persistence contexts, we will need a way to ensure that stateful session
beans that are related (direct or indirectly) through extended
persistence context inheritance, will need to fail-over as a group in
the cluster. If we come up with a load balancing policy that covers
that magically, that would be cool. I'll add more details on the "EJB
passivation/activation, clustering and JPA extended persistence context
handling..." thread...