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

  • From: Alexander Gorbachev <gorbyx@xxxxxxxxx>
  • To: "oracle-L@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
  • Date: Mon, 14 Mar 2005 23:07:20 +0100

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@xxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l

Other related posts: