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

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@xxxxxxxxxxxxxxxxx
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx =
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Tim Gorman
Sent: Monday, March 14, 2005 1:24 PM
To: oracle-L@xxxxxxxxxxxxx
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@xxxxxxxxx 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

Other related posts: