| Groups | Blog | Home |
sql server notification services : Chronicles
I seem to recall that notifications can leverage chronicles to eliminate duplicate notifications for an event, such that key information that might be triggered is only sent if what was sent before is different. I cannot seem to find the reference to this. Any direction would be
Hello,
I seem to remember you saying you had a copy of my book. If that's so, you'll find a detailed discussion of chronicles in Chapter 6. They're also covered in the books online and, I think, the stock sample that comes with the product. The gist of it is that you can define arbitrary tables to hold state for your application. Chronicles can be associated with event classes or subscription classes. Event class chronicles are updated by chronicle rules that you define in the ADF as part of the event class. These rules look similar to match rules, but rather than generating notifications, they simply update whatever state you keep in your chronicle tables, based on the latest event data. Subscription chronicles are updated as part of the regular match rules. To handle the duplicate notifications scenario as you've described it, you could keep a subscription chronicle that holds information about which subscribers were notified about what. You update this table every time you generate a notification. In your match rule, you join in this table and use it to filter out rows that you don't need to notify about again. There are many variations of this e.g. never send duplicates, send a duplicate if a certain amount of time has elapsed, send a duplicate if some data value has changed beyond a threshold etc. All can be handled via chronicles. -shyam -- Learn more about SQL-NS: http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/ --------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm. --------------------------------------------- [quoted text, click to view] "andyjax" <andyjax@newsgroup.nospam> wrote in message news:E1F1546C-7D1D-4A8A-AFEF-92CC6FCE2B96@microsoft.com... > Ok my mind is becoming mush after reading so much. > > I seem to recall that notifications can leverage chronicles to eliminate > duplicate notifications for an event, such that key information that might > be > triggered is only sent if what was sent before is different. > > I cannot seem to find the reference to this. Any direction would be > appreciated.
Yes I have your book. I lightly read over chapter 6, but it did not seem to
address my needs. Is is bad to join to the NS<NotificationClassName>Notifications table directly? If I join it, then that will cause more overhead, but seems to be the way to eliminate duplicates. I will take a look at the other samples. Thanks. [quoted text, click to view] "Shyam Pather [MSFT]" wrote:
> Hello, > I seem to remember you saying you had a copy of my book. If that's so, > you'll find a detailed discussion of chronicles in Chapter 6. They're also > covered in the books online and, I think, the stock sample that comes with > the product. > > The gist of it is that you can define arbitrary tables to hold state for > your application. Chronicles can be associated with event classes or > subscription classes. Event class chronicles are updated by chronicle rules > that you define in the ADF as part of the event class. These rules look > similar to match rules, but rather than generating notifications, they > simply update whatever state you keep in your chronicle tables, based on the > latest event data. Subscription chronicles are updated as part of the > regular match rules. > > To handle the duplicate notifications scenario as you've described it, you > could keep a subscription chronicle that holds information about which > subscribers were notified about what. You update this table every time you > generate a notification. In your match rule, you join in this table and use > it to filter out rows that you don't need to notify about again. There are > many variations of this e.g. never send duplicates, send a duplicate if a > certain amount of time has elapsed, send a duplicate if some data value has > changed beyond a threshold etc. All can be handled via chronicles. > -shyam > > > -- > Learn more about SQL-NS: > http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/ > --------------------------------------------- > This posting is provided "AS IS" with no warranties, and confers no rights. > Use of included script samples are subject to the terms specified at > http://www.microsoft.com/info/cpyright.htm. > --------------------------------------------- > "andyjax" <andyjax@newsgroup.nospam> wrote in message > news:E1F1546C-7D1D-4A8A-AFEF-92CC6FCE2B96@microsoft.com... > > Ok my mind is becoming mush after reading so much. > > > > I seem to recall that notifications can leverage chronicles to eliminate > > duplicate notifications for an event, such that key information that might > > be > > triggered is only sent if what was sent before is different. > > > > I cannot seem to find the reference to this. Any direction would be > > appreciated. > >
Chapter 6 generally covers the syntax of chronicles and how to use them but,
you're right, it doesn't specifically address your scenario. However, the pattern I show in the example where the subscription chronicle stores the last processing time for each subscription will also work for your example. Instead of storing the last processing time, you should store whatever criteria you use to determine if something is a duplicate. You should never join the NS<NotificationClassName>Notifications table directly. There are several reasons for this: - The contents are never guaranteed - NS can delete old rows at any time as part of cleanup. - The schema is not guaranteed to stay the same across NS versions. - The indexes etc. on the table are optimized for the specific queries that the NS stored procs run against it. If you run other queries, it's quite possible that you'll introduce contention/deadlocks in high throughput scenarios. -shyam -- Learn more about SQL-NS: http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/ --------------------------------------------- This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm. --------------------------------------------- [quoted text, click to view] "andyjax" <andyjax@newsgroup.nospam> wrote in message news:2D470FEC-2F57-4B6A-BAF3-E3E41FC6600B@microsoft.com... > Yes I have your book. I lightly read over chapter 6, but it did not seem > to > address my needs. Is is bad to join to the > NS<NotificationClassName>Notifications table directly? If I join it, then > that will cause more overhead, but seems to be the way to eliminate > duplicates. I will take a look at the other samples. > > Thanks. > > "Shyam Pather [MSFT]" wrote: > >> Hello, >> I seem to remember you saying you had a copy of my book. If that's so, >> you'll find a detailed discussion of chronicles in Chapter 6. They're >> also >> covered in the books online and, I think, the stock sample that comes >> with >> the product. >> >> The gist of it is that you can define arbitrary tables to hold state for >> your application. Chronicles can be associated with event classes or >> subscription classes. Event class chronicles are updated by chronicle >> rules >> that you define in the ADF as part of the event class. These rules look >> similar to match rules, but rather than generating notifications, they >> simply update whatever state you keep in your chronicle tables, based on >> the >> latest event data. Subscription chronicles are updated as part of the >> regular match rules. >> >> To handle the duplicate notifications scenario as you've described it, >> you >> could keep a subscription chronicle that holds information about which >> subscribers were notified about what. You update this table every time >> you >> generate a notification. In your match rule, you join in this table and >> use >> it to filter out rows that you don't need to notify about again. There >> are >> many variations of this e.g. never send duplicates, send a duplicate if a >> certain amount of time has elapsed, send a duplicate if some data value >> has >> changed beyond a threshold etc. All can be handled via chronicles. >> -shyam >> >> >> -- >> Learn more about SQL-NS: >> http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/ >> --------------------------------------------- >> This posting is provided "AS IS" with no warranties, and confers no >> rights. >> Use of included script samples are subject to the terms specified at >> http://www.microsoft.com/info/cpyright.htm. >> --------------------------------------------- >> "andyjax" <andyjax@newsgroup.nospam> wrote in message >> news:E1F1546C-7D1D-4A8A-AFEF-92CC6FCE2B96@microsoft.com... >> > Ok my mind is becoming mush after reading so much. >> > >> > I seem to recall that notifications can leverage chronicles to >> > eliminate >> > duplicate notifications for an event, such that key information that >> > might >> > be >> > triggered is only sent if what was sent before is different. >> > >> > I cannot seem to find the reference to this. Any direction would be >> > appreciated. >> >> >>
[quoted text, click to view]
>address my needs. Is is bad to join to the >NS<NotificationClassName>Notifications table directly? If I join it, then Yes...apart from the standard "don't mess with the underlying tables" objection, the notifications table is subject to vacuuming. So when the vacuumer comes along and gets rid of "obsolete" data, you may end up sending notifications again. Chron tables aren't difficult to use and are pretty flexible. A couple of classic examples come to mind....they can be used provide summary information (ie highest and lowest stock price for the day) as well as for minimizing unwanted notifications (ie notify me the first time the stock price exceeds my threshold, but don't keep notifying me every 15 sec afterwards)....just to name a couple. HTH... -- Joe Webb SQL Server MVP ~~~ Get up to speed quickly with SQLNS http://www.amazon.com/exec/obidos/tg/detail/-/0972688811 I support PASS, the Professional Association for SQL Server. (www.sqlpass.org) On Thu, 7 Jul 2005 12:32:12 -0700, "andyjax" [quoted text, click to view] <andyjax@newsgroup.nospam> wrote:
>Yes I have your book. I lightly read over chapter 6, but it did not seem to >address my needs. Is is bad to join to the >NS<NotificationClassName>Notifications table directly? If I join it, then >that will cause more overhead, but seems to be the way to eliminate >duplicates. I will take a look at the other samples. > >Thanks. > >"Shyam Pather [MSFT]" wrote: > >> Hello, >> I seem to remember you saying you had a copy of my book. If that's so, >> you'll find a detailed discussion of chronicles in Chapter 6. They're also >> covered in the books online and, I think, the stock sample that comes with >> the product. >> >> The gist of it is that you can define arbitrary tables to hold state for >> your application. Chronicles can be associated with event classes or >> subscription classes. Event class chronicles are updated by chronicle rules >> that you define in the ADF as part of the event class. These rules look >> similar to match rules, but rather than generating notifications, they >> simply update whatever state you keep in your chronicle tables, based on the >> latest event data. Subscription chronicles are updated as part of the >> regular match rules. >> >> To handle the duplicate notifications scenario as you've described it, you >> could keep a subscription chronicle that holds information about which >> subscribers were notified about what. You update this table every time you >> generate a notification. In your match rule, you join in this table and use >> it to filter out rows that you don't need to notify about again. There are >> many variations of this e.g. never send duplicates, send a duplicate if a >> certain amount of time has elapsed, send a duplicate if some data value has >> changed beyond a threshold etc. All can be handled via chronicles. >> -shyam >> >> >> -- >> Learn more about SQL-NS: >> http://www.amazon.com/exec/obidos/tg/detail/-/0672326647/ >> --------------------------------------------- >> This posting is provided "AS IS" with no warranties, and confers no rights. >> Use of included script samples are subject to the terms specified at >> http://www.microsoft.com/info/cpyright.htm. >> --------------------------------------------- >> "andyjax" <andyjax@newsgroup.nospam> wrote in message >> news:E1F1546C-7D1D-4A8A-AFEF-92CC6FCE2B96@microsoft.com... >> > Ok my mind is becoming mush after reading so much. >> > >> > I seem to recall that notifications can leverage chronicles to eliminate >> > duplicate notifications for an event, such that key information that might >> > be >> > triggered is only sent if what was sent before is different. >> > >> > I cannot seem to find the reference to this. Any direction would be >> > appreciated. >> >> >>
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
| home · blog · groups | Questions? Comments? Contact the dn |