Re: DBMS_JOB, Distributed transactions and logging.

Thank you, Marc!
This is what we decided on doing since we use queues for a lot of other inter-server communication. The PIPE would not really work due to complexity of data that is being logged. It is not just a plain stream...

Thanks again for the response.

Other ideas? Will Oracle fix the transaction management in 9i (or 8i patches)?

Marc Billiet <marcREMOVE.bilietTHIS_at_bigfoot.com> wrote in message news:<alq78u$pdn$1_at_vkhdsu24.hda.hydro.com>...
> Alex Vilner heeft geschreven:
> > Hi,
> >
> > We have a classic distributed transaction scenario. A local 8i (8.1.7)
> > server initiates the transaction, does some processing, calls a remote
> > procedure on another 8i server over the DB link... Both are running on
> > Solaris.
> >
> > We are aware of transaction control not working on the remote side in
> > distributed transactions, but we have not much control over the local
> > server processes. The task we are faced with is to log errors on the
> > remote server, and keep them logged (in tables) even if the
> > transaction rolls back.
> >
> > The approach was to try and use DBMS_JOB in the exception block of the
> > remote procedures. However, it seems that DBMS_JOB does not add a job
> > to the queue unless there is a commit OR unless DBMS_JOB.RUN (implicit
> > commit) is called. Is there a workaround this issue?
> >
> > Thank you in advance!
>
> What we do is sending the error message to a queue (dbms_aq). This queue
> is dequeued by another job which inserts the messages into a table (of
> course, the messages can be kept in the queue table as well). You can
> also use dbms_pipe, which is easier to use.
> Dbms_alert can't be used, because alerts are only sent after a commit.
>
> Marc
Received on Thu Sep 12 2002 - 15:16:19 CDT