you could have a DBMS_JOB that polls the notification table and pushes the
notification records down the DBMS_PIPE
but, why not just have your middle application poll the notification table
and then pass them on to the clients... you also may want to look into using
DBMS_ALERT instead of DBMS_PIPE
--
----------------------------------------
Mark C. Stock
www.enquery.com
(888) 512-2048
"roger" <vrsr_at_rogerware.com> wrote in message
news:Xns941DB08CD81E0rsrrogerwarecom_at_204.127.204.17...
> Daniel Morgan <damorgan_at_x.washington.edu> wrote in news:1066949322.260859
> @yasure:
>
> > roger wrote:
> > AFTER UPDATE trigger writes notification to a table
> >
> > DBMS_PIPE sends communication directly to C program
>
>
> Thanks for the reply.
>
> Why the intermediary step of writing to the table?
> Why not just write the notification data to the pipe?
>
>
> The other way I imagined was to create an external 'C'
> routine that would queue messages (perhaps to a UNIX pipe:)
> rather than using the DBMS_PIPE package.
> But hey, if DBMS_PIPE is easier, that's fine with me:)
>
> Either way - one wrinkle I forsee is that the pipe
> reader will potentially be notified before the
> change to the table is comitted, or perhaps even rolled back.
>
> Is there any mechanism to cause a trigger like this
> to fire only after the transaction is comitted?
>
> I don't see it off hand.
>
> Thanks.
>
>
>
Received on Thu Oct 23 2003 - 19:49:32 CDT
