Re: Distributed transactions (two-phase commint) without DB links

Well, it's been an internal policy to simplify management of the environment. The environment has to be very reliable. On the other hand, it's quite dynamic - developing quickly so we have quite a few test phases, many of which are refreshed from production so there is some risk to connect to production DB unintentionally.

I understand that there might be certain procedures in place to avoid it but it requires effort and still some risk (at least from management perspective).

DB links represent one more dependency so that's one more chain to break. Without links it's much easier to troubleshoot possible connection problems because it's localized.

Communication between different applications (all OLTP) is always done with standard messages. Data movement is done using import/export/TTS whenever possible etc. In general, all applications are designed in such a way that DB links are not really required because functionality is decoupled.

So ideally we would like to stick to the rules. :) I agree that for some applications links are handy but we try to avoid them. It all depend on price to pay.

On Mon, 14 Mar 2005 14:24:26 -0700, Tim Gorman <tim_at_evdbt.com> wrote:
> For 9i, check out "OCITransPrepare()", "OCITransForget()",
> "OCITransCommit()", and "OCITransRollback()".
>
> Now for my question: what's so terrible about database links? To put it
> another way, what's so good about being "link free"? What is "unacceptable"
> about them?
>
> Is dragging the data back and forth across a SQL*Net connection to a 3GL
> program better than doing it inside the database? Is all this low-level OCI
> coding better, faster, or more portable than simply letting the database
> handle it transparently?
>
> Enquiring minds want to know... :-)

-- 
Best regards,
Alex Gorbachev
--
http://www.freelists.org/webpage/oracle-l