SPE to SPE signaling

From Cellbe

Revision as of 19:13, 20 November 2015 (edit) 221.178.182.21 (Talk) (1IMWAbaA) ← Previous diff		Current revision as of 19:44, 20 November 2015 (edit) (undo) 221.178.182.27 (Talk) (KgFL8vduSxcM)
Line 1:		Line 1:
-	Hi Kevin  I agree with RJL that WAN clustering rcdeeus administration immensely.  In fact, we originally had 3 separate SA nodes across the globe and were using push config to keep them in sync until we realized that this was killing all of the client sessions on the push targets each time we pushed the config.  That did not go over too well, so we switched to an A/A 3 node WAN cluster.	+	Denny,There IS a bug in the incrementing of the major vsoeirn.  I've fixed it in SVN, but haven't made a new public release with the fix (one more entry on my list of things to do "sometime").  Since the major vsoeirn only updates between migrations, the bug can only manifest itself if there is an issue with the first step of a given migration, but you're right, there is an issue there.  The minor vsoeirns (steps within a migration) are double protected: the increment happens second, and the whole thing is wrapped in a CFTRANSACTION.  The reason the major vsoeirn increments first is for internal bookkeeping reasons.  It's safe for it to increment even if the first migration step fails, because it'll be minor vsoeirn zero (which means the first step is still next in line). The bug was in when the minor vsoeirn was reset to zero; it happened at the wrong time before.For the two-developer conflict scenario, there's nothing the tool can do about it.  You have to resolve the conflicts when the second developer commits his/her changes.  Migration code does have some ordering ramifications, so resolving a conflict might not be as simple as otherwise (quite possibly requiring manual tweaks to the `schema_version` table), but it's really no different from any other conflict between multiple developers.

---

Current revision as of 19:44, 20 November 2015

Denny,There IS a bug in the incrementing of the major vsoeirn. I've fixed it in SVN, but haven't made a new public release with the fix (one more entry on my list of things to do "sometime"). Since the major vsoeirn only updates between migrations, the bug can only manifest itself if there is an issue with the first step of a given migration, but you're right, there is an issue there. The minor vsoeirns (steps within a migration) are double protected: the increment happens second, and the whole thing is wrapped in a CFTRANSACTION. The reason the major vsoeirn increments first is for internal bookkeeping reasons. It's safe for it to increment even if the first migration step fails, because it'll be minor vsoeirn zero (which means the first step is still next in line). The bug was in when the minor vsoeirn was reset to zero; it happened at the wrong time before.For the two-developer conflict scenario, there's nothing the tool can do about it. You have to resolve the conflicts when the second developer commits his/her changes. Migration code does have some ordering ramifications, so resolving a conflict might not be as simple as otherwise (quite possibly requiring manual tweaks to the `schema_version` table), but it's really no different from any other conflict between multiple developers.