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

From: MacGregor, Ian A. <ian_at_slac.stanford.edu>
Date: Mon, 14 Mar 2005 13:41:34 -0800
Message-ID: <7F24308CD176594B8F14969D10C02C6C3B7EAE@exch-mail2.win.slac.stanford.edu>

I most heartedly agree; db links are the way to go. =20

Now if they would just get rid of that plain text password in = user_db_links. Yes, I know you can recreate the view to leave it out, = but that's a pain, and it still remains in sys.link.=20

Ian MacGregor
Stanford Linear Accelerator Center
ian_at_SLAC.Stanford.edu
-----Original Message-----
From: oracle-l-bounce_at_freelists.org =
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Tim Gorman Sent: Monday, March 14, 2005 1:24 PM
To: oracle-L_at_freelists.org
Subject: Re: Distributed transactions (two-phase commint) without DB = links

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... :-)

on 3/14/05 12:54 PM, Alexander Gorbachev at gorbyx_at_gmail.com wrote:

> Hi all,

>=20

> We are facing the problem with design of a new application.
> Historically, we have been successful in pursuing our rules that DB
> links are not acceptable in our environment. Until now, we've managed
> to follow this rule and stay "link-free".

>=20

> Developers of a new project reqire DB links. The problem is that
> project deadlines are very pressing and we might be forced to comply
> with their requirements for distributed transactions on the database
> tier. I don't think that there will be any TP monitor in use so
> probably no help from this side.

>=20

> I have briefly reviewed Oracle documentation and found that there are
> some OCI functions for implementation of distributed transactions. As
> far as I understand it's possible to apply them on OCI client side (to
> be precise, I couldn't find that it's not possible so I assumed) so
> that a binary can open two sessions and commit globally.

>=20

> I would be very interesting if someone could share any experince with
> that. White papers, feasibility, complexity, problems, etc.

>=20

> To define the problem again:
> ---------------------
> We need a way to connect from application tier to two (or more)
> databases and perform global transaction with two-phase commit.
> ---------------------

>=20
> Thanks in advance!

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

Received on Mon Mar 14 2005 - 16:45:01 CST