Summary

Scheduled subscriptions allow subscribers to specify when they should be evaluated: The evaluation of scheduled subscriptions is not triggered by event arrival. In situations where event frequency and subscription selectivity are such that event-triggered subscriptions would produce too many notifications for a subscriber to handle, scheduled subscriptions provide a convenient alternative.

To support scheduled subscriptions, applications need to keep an event history. This is because scheduled subscriptions may be evaluated long after the events have already been processed. Every time a batch of events arrives, the event history can be updated with the new event data. SQL-NS supports event chronicles as a means to maintain event history. You can create chronicle tables, as well as chronicle rules that update them, as part of the event class declaration. SQL-NS executes the chronicle rules when new events arrive.

Like event triggered subscriptions, scheduled subscriptions are represented by subscription classes. A scheduled subscription class has essentially the same structure as an event-triggered subscription class: It has a schema for the subscription data and a set of rules that do matching. However, the rules in a scheduled subscription class are declared as scheduled rules and are not associated with any event class.

In many cases, applications need to keep state about each scheduled subscription. Typically, this is used to ensure that scheduled subscriptions are evaluated only against new data added to the event history after the previous evaluation. Subscription state is maintained through subscription chronicles, and SQL-NS provides a way to declare subscription chronicles as part of a subscription class. The logic that updates the subscription chronicle tables is mixed in with the match logic in the subscription class's scheduled rules.

In this chapter, we prototyped scheduled subscriptions for the music store application. We built the event chronicles and chronicle rules required to maintain event history, and then built the scheduled subscription class. The subscription class declares a chronicle that maintains the last time each scheduled subscription was evaluated. This subscription chronicle is used in the match rule to filter out parts of the event history that have already been seen.

After testing the scheduled subscriptions, we tested the whole prototype from end to end. We deleted the instance, application, and music store databases, and cleaned up the input and output files used in testing. We then recompiled the whole instance from scratch and tested all its features. Doing this validates that the prototype is complete and works as expected. Having established this, we can continue to build on this prototype in the upcoming chapters and turn it into a real application.