roger wrote:
>Daniel Morgan <damorgan_at_x.washington.edu> wrote in news:1067014454.263734
>@yasure:
>
>
>
>>Triggers in Oracle are atomic just like the rest of the code. It does
>>not work like SQL Server
>>where they are all independent. So ignore whether the trigger fires ...
>>it is irrelevant. If the
>>code or procedure commits the actions of the trigger are commited. If
>>they rollback they
>>rollback the trigger's actions too.
>>
>>
>>
>
>Understood.
>
>The problem is with any actions the trigger might take which
>aren't part of the transaction context, for example writing a
>message out to a pipe.
>
>If I do it that way, then the problem is that a message reader
>could see the messages regarding transactions that haven't
>happened yet (not committed) or could see messages about changes
>that never take place (because the transaction gets rolled back)
>
>So, if there's no way to delay the trigger til the transaction
>is committed, then I shall have to go the way of writing
>messages to an alternate table.
>
>Not a big deal, just means that I have to continuously be
>polling this notification table, rather than simply block
>on a read from a pipe.
>
>
>
I agree with Rene. DBMS_PIPE is not the correct tool for you. Look at
DBMS_ALERT or
at the other option I presented ... logging a record into a table.
--
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)
Received on Fri Oct 24 2003 - 15:17:01 CDT
