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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/jboss-as7-dev