<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Sorry, should be:<div><br></div><div>Let say 5 Node Cluster.<br><br>Simpel Case without references between SFSBs<br>First Cluster Member with 4 independen SFSBs.<br><br>SFSB1 uses XPC1<br>SFSB2 uses XPC2<br>SFSB3 uses XPC3<br>SFSB4 uses XPC4<br><br>One remote Client connected to first Cluster Member keeping remote ref to all four SFSBs<br>First Node get killed ( kill -9 )<br><br>If I understund Scott correctly this result in 4 LoadBalanced migration groups.<br>LoadBalancing "round robin" each SFSB goes to different cluster member.<br><br>Remote Client needs then 4 new remote connections....does this need more time ????<br><br>Assume now no LoadBalancing on failOver.<br><br>All SFSBs fails over to same Cluster Member.<br><br>Remote Client needs 1 new remote connection...<br>Don't need to figure out any relations ( faster ) because all SFSBs and all XPCs are on same Cluster Node.<br><br>Cluster just defines which nodes replicates to which nodes. On FailOver One Cluster Member needs new Node for replication.</div><div><div><br><div><br><div>Anfang der weitergeleiteten E-Mail:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Von: </b></span><span style="font-family:'Helvetica'; font-size:medium;">Radoslaw Rodak <<a href="mailto:rodakr@gmx.ch">rodakr@gmx.ch</a>><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Datum: </b></span><span style="font-family:'Helvetica'; font-size:medium;">3. Dezember 2011 01:49:28 MEZ<br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>An: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><a href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br></span></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px;"><span style="font-family:'Helvetica'; font-size:medium; color:rgba(0, 0, 0, 1);"><b>Betreff: </b></span><span style="font-family:'Helvetica'; font-size:medium;"><b>Re: [jboss-as7-dev] EJB passivation/activation, clustering and JPA extended persistence context handling...</b><br></span></div><br><div>Let say 5 Node Cluster.<br><br>Simpel Case without references between SFSBs<br>First Cluster Member with 5 independen SFSBs.<br><br>SFSB1 uses XPC1<br>SFSB2 uses XPC2<br>SFSB3 uses XPC3<br>SFSB4 uses XPC4<br><br>One remote Client connected to first Cluster Member keeping remote ref to all five SFSBs<br>First Node killed ( kill -9 )<br><br>If I understund Scott correctly this result in 4 LoadBalanced migration groups.<br>Worst Case State replicated over 4 Nodes.<br><br>Remote Client needs then 4 new remote connections....does this need more time ????<br><br>Assume now no LoadBalancing on failOver.<br><br>All SFSBs goest to let say second Cluster Member.<br><br>Remote Client needs 1 new remote connection...<br>Don't need to figure out any relations ( faster ) because all SFSBs and all XPCs are on same Cluster Node.<br><br>Cluster just defines which nodes replicates to which nodes. On FailOver One Cluster Member needs new Node for replication.<br><br><br>Am 02.12.2011 um 23:27 schrieb Brian Stansberry:<br><br><blockquote type="cite">On 12/2/11 4:22 PM, Scott Marlow wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">On 12/02/2011 04:38 PM, Jason T. Greene wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On 12/2/11 2:55 PM, Scott Marlow wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">We also know that we need to replicate the serialization group (as its<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">definition changes dynamically). For example, the application has five<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">stateful session beans (SFSB1-SFSB5) that are associated with three<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">extended persistence contexts (XPC1-XPC3). The relationships between<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">these five beans are as follows:<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> SFSB1 uses XPC1<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> SFSB2 uses XPC1 and has reference to SFSB3<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> SFSB3 uses XPC2<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> SFSB4 uses XPC2 and has reference to SFSB5<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"> SFSB5 uses XPC3<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">When SFSB1 fails over, we need to fail-over its working set (the<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">serialization group which includes SFSB1, SFSB2, SFSB3, SFSB4, SFSB5,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">XPC1, XPC2, XPC3). In case its not obvious why, SFSB2 may have pending<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">database updates in XPC1, so it must fail-over also to the same target<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">node. Since SFSB2 has a reference to SFSB3, SFSB3 needs to fail-over<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">together with the group also (and so the pattern continues for SFSB4,<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">SFSB5, XPC3).<br></blockquote></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">The above is the application correctness issue. If SFSB2 fails over to<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">a different node than SFSB4, the extended persistence context could be<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">used on two different nodes. Basically, the extended persistence<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">context can live through several non-transactional invocations. When a<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">transaction is finally started on SFSB3 or SFSB4, the XPC2 changes will<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">finally be committed.<br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">I still don't this is right. those references go across a proxy, and the<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">proxy's backing data can be anywhere.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I should of added that SFSB2 has a local reference to SFSB3 (which means<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">they originates on the same JVM). I assumed that SFSB2 is migrated to<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">the same target node as SFSB3 to keep the reference local (during a<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">fail-over). No matter, where SFSB3 goes, SFSB4 needs to be on the same<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">node (to share the same extended persistence context).<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">The SFSBs themselves, can be anywhere but the extended persistence<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">context, needs to stay with the SFSBs that inherit it.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Maybe there is another way to tackle this that I'm not seeing but I<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">wanted to mention these details to whomever is following this thread.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">BTW, is there any spec requirement that prohibits concurrent access to <br></blockquote><blockquote type="cite">an XPC?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">-- <br></blockquote><blockquote type="cite">Brian Stansberry<br></blockquote><blockquote type="cite">Principal Software Engineer<br></blockquote><blockquote type="cite">JBoss by Red Hat<br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">jboss-as7-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br></blockquote><blockquote type="cite"><a href="https://lists.jboss.org/mailman/listinfo/jboss-as7-dev">https://lists.jboss.org/mailman/listinfo/jboss-as7-dev</a><br></blockquote><br><br>_______________________________________________<br>jboss-as7-dev mailing list<br><a href="mailto:jboss-as7-dev@lists.jboss.org">jboss-as7-dev@lists.jboss.org</a><br>https://lists.jboss.org/mailman/listinfo/jboss-as7-dev<br></div></blockquote></div><br></div></div></body></html>