Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Are triggers serialized?

Re: Are triggers serialized?

From: Brian Peasland <dba_at_remove_spam.peasland.com>
Date: Mon, 27 Oct 2003 15:16:29 GMT
Message-ID: <3F9D36CD.4B6A410E@remove_spam.peasland.com>


Yes. If you do a rollback on the INSERT statement, then the triggers work will be rolled back as well.

HTH,
Brian

Mark Wayne wrote:
>
> Thanks Kenneth.
> Another question: does the trigger run in the same process/thread context as
> the process which issued the SQL INSERT statement?
>
> mark
>
> <Kenneth Koenraadt> wrote in message
> news:3f9a8c2b.4539537_at_news.inet.tele.dk...
> > On Sat, 25 Oct 2003 14:37:52 GMT, "Mark Wayne" <spam_at_earthlink.net>
> > wrote:
> >
> > >I'm just learning some PL SQL. If multiple processes are inserting into a
> > >table, will multiple instances of my trigger execute, possibly
> > >simultaneously?
> > >
> > >Thanks,
> > >mark
> > >
> > >
> >
> > Hi Mark,
> >
> > Trigges are serialized in the sense that 2 triggers cannot update the
> > same rows simultanously. So things won't get messed up, because
> > Oracle ensures *read consistency*, e.g. :
> >
> > Process 1 (P1)inserts into a table, which causes a trigger to fire and
> > update several rows in this and other tables.
> >
> > process 2 (P2) inserts into that table, the trigger fires again and
> > updates several rows in this and other tables, possibly same rows that
> > were affected by P1.
> >
> > If P1 has not committed before P2 starts its update, P2 must wait for
> > P1 to commit in order to him to update. If P2 just needs to read the
> > rows P1 is updating, it fetches the before-update image in
> > rollback-segments.
> >
> > But a deadlock between P1 and P2 may occur. If the trigger updates
> > several tables /several rows, deadlocks become more likely. And the
> > more simultaneous trigger-firing events happen, the more likely
> > deadlocks.
> >
> > That's one of more major drawbacks with triggers.
> >
> > At first, they do things behind the back. That means the developer
> > constantly needs to withhold his ordinary code with the trigger code.
> > It can be tedious and increases the likelihood of errors.
> >
> > At second, they don't scale well : Both at the system level (e.g.
> > deadlocks) and at the application level. When an application grows in
> > functionality, the triggers must handle more and more specific cases,
> > and the interaction between triggers and other code becomes more
> > tedious.
> >
> > Not that triggers are just bad. Just use them with care.
> >
> >
> > - Kenneth Koenraadt
> >
> >
> >
> >
> >
> >
> >
> >
> >

-- 
===================================================================

Brian Peasland
dba_at_remove_spam.peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
 the three"
Received on Mon Oct 27 2003 - 09:16:29 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US