RE: Two-Phase commit to avoid replication delay??

From: STEVE OLLIG <sollig_at_lifetouch.com>
Date: Tue, 15 Feb 2005 08:36:27 -0600
Message-ID: <DFA54221DF26D911BC5100B0D079D97A800C26@exchmn2.lifetouch.com>

> So we like to implement two-phase commit solution to avoid
> replacation delay for these 3 tables.

...
> We understand that there would be performance hit (2 writes instead of
> one write) and network latency.
>
> Is there any other issues in this approach?

Each write would likely take longer increasing the chance of lock contention between multiple writers.

> When the other DB becomes available, the queue will be pushed into the
> remote db using some mechanish(say DBMS_JOB).

and would't you have to let this DBMS_JOB thingy apply all the queued transactions before allowing any new transactions in the database that was down? Likewise, any new transactions from the active database would still need to be applied after the DBMS_JOB thingy. Tricky.

---

This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email

---

--
http://www.freelists.org/webpage/oracle-l

Received on Tue Feb 15 2005 - 10:28:38 CST