Re: DBMS_PIPE vs DBMS_ALERT

Thanks so much for your replies. Actually, I had a very insightful thread on this topic couple of weeks ago and learned alot. I decided to go with the dbm_pipe interface.

My requirement is to build a very scalable system that detects change in a table or view (relating multiple tables) via a trigger. This trigger sends information to an event consumer (client process(es)) which in turn send out email notifications.

Now the key thing here is that it has to scale for potentially millions of users or lets say ~1000 per second column/row updates with corresponding trigger fires. The event consumers are multithreaded and can handle large number of events.

Now I did read up on AQ etc, also had some insightful discussions on this forum. For now I am doing it with DBM_PIPE, I dont really know how this will scale. I know that if one of the pipe ends goes down, I need to manage the reconnection etc; this is what I meant by "unreliable", maybe my terminology wasn't right.

In any case, please advice me on the approach for a highly scalable trigger based notification application
(pushing a light weight event out from trigger in a large
scale deployment).

I am also interested in understand trigger overhead, can triggers become a performance bottleneck, especially if one is doing joins etc... Is it better to put this processing in a trigger (let the server do the processing) rather than the middle tier
(distributed middle tier) ??

Any suggestions appreciated.

Thanks and best regards.
Furkan Received on Wed May 26 1999 - 02:48:53 CDT