On Thursday, 24 February, 2011 09:46 AM, Douglas Hubler wrote: > On Wed, Feb 23, 2011 at 6:44 PM, Joegen Baclor<[email protected]> wrote: >> What if we simply invert 1 and 2 and forget about 2-3 all together if 1 >> succeeds? > I see where you're going, but we cannot guarantee the REGISTRATION > makes is back thru normal mongo replication. If you can solve that > w/o blocking the SIP transaction then sure. What I think you'll find > is that you'd just be creating a FIFO queue in memory that > accomplished kinda the same thing only less resilient to server > restarts because it wouldn't be using mongo to store the pending > REGISTRATION that have yet to make a round trip. >
I concede. However, how does the master DB compute delta when syncing write operations with the slave registration db? is this transactional or computed against the entire BSON document? I suggest that we have two sets of DB's. imdb.local.registrar -> imdb.shared.registrar the guaranty the integrity of the master slave setup instead of allowing slaves to write the the replicated (which they should not do IMHO). 1. Slave writes to imdb.local.registrar 2. Slave replicates to master Redirect process. 1. INVITE goes in. 2. Registrar queries imdb.local.registrar 3. If not found, fallback to imdb.shared.registrar 4. If not found on both, allow fallback rules to take precedence. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
