There's nothing wrong with polling as long as it's moderate and it doesn't lock resources.
On a heavily updated table in a large volumen site, it scales much better than nasty triggers or events firing all over the place. Triggers are intended to maintain internal database consistency by enforcing business rules at the DB tier. They're not meant for event notification of external applications, especially if you're holding the transaction hostage until the remote call is completed. As someone mentioned here, asynchronous events (fire'n'forget) in some DBMS systems are much better suited to this because they don't don't prolong transactions, and subsequently locks on resources. I think the best choice in your scenario is to use adaptive polling: Track the average of DELTA (new records added between polls) over time, and adjust the polling internval accordingly. For example, if the current average DELTA is 100, and the new DELTA was 120, then you decrease the polling interval proportionally but not less than MIN value, and if it was 80, then you increase the polling interval proportionally but not greater than MAX value. This way you can adapt well to surges in events and prevent queue buildups. Homam --- Michael Gale <[EMAIL PROTECTED]> wrote: > Hello, > > I am fairly new to mysql and have a strange request > .... I am not sure > if "stored procedures" will solve this. > > I have a table in a database that is constantly > being updated with new > information. I would like to be notified if certain > information gets > committed. > > Lets say for example the table gets updated every > time a login attempt > happens regardless if it is successful or not. > > So I want an app to watch the table for incorrect > logins and if found to > send an e-mail. > > Now there are several problems with this ... > first... there could be > hundreds of logins so we do not want the same app to > spawn multiple > processes each notifying the same incorrect login > attempt. > > I was thinking about a cron that would run every X > minute searching any > newly added rows and keeping the last row id in a > tmp file. > > Is there a better way ? > > Thanks. > > Michael. > > -- > MySQL General Mailing List > For list archives: http://lists.mysql.com/mysql > To unsubscribe: > http://lists.mysql.com/[EMAIL PROTECTED] > > -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
