microsoft.public.sqlserver.notificationsvcs
[Top] [All Lists]

Re: Chronicles

Subject: Re: Chronicles
From: "Shyam Pather [MSFT]"
Date: Thu, 7 Jul 2005 12:45:50 -0700
Newsgroups: microsoft.public.sqlserver.notificationsvcs
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.
---------------------------------------------
"andyjax" <[email protected]> wrote in message 
news:[email protected]
> 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" <[email protected]> wrote in message
>> news:[email protected]
>> > 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.
>>
>>
>> 



<Prev in Thread] Current Thread [Next in Thread>