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,
>
> 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".
>
> 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.
>
> 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.
>
> I would be very interesting if someone could share any experince with
> that. White papers, feasibility, complexity, problems, etc.
>
> 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.
> ---------------------
>
> Thanks in advance!

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