US7805422B2

US7805422B2 - Change notification query multiplexing

Info

Publication number: US7805422B2
Application number: US11/067,778
Authority: US
Inventors: Lijiang Fang; Hua Yuan
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2005-02-28
Filing date: 2005-02-28
Publication date: 2010-09-28
Also published as: US20060195456A1

Abstract

In order to efficiently handle change notification requests to a storage system based on a database data store and a database engine, the change notification requests are multiplexed. This can be done by issuing a query which refers, for information about what changes are being tracked, to a data structure. The information about what changes to track for each request to be multiplexed is stored in the data structure. Additionally, information about the request can be stored in the data structure. By adding information to the data structure, the query can be altered without needing to directly modify or reissue the query.

Description

CROSS-REFERENCE

This application is related by subject matter to the inventions disclosed in the following commonly assigned applications: U.S. patent application Ser. No. 10/646,646, filed on Aug. 21, 2003 entitled “STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA”; U.S. patent application Ser. No. 10/647,058, filed on Aug. 21, 2003, entitled “SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION”; U.S. patent application Ser. No. 10/646,941, filed on Aug. 21, 2003, entitled “SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION”; U.S. patent application Ser. No. 10/646,940, filed on Aug. 21, 2003, entitled “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM”; U.S. patent application Ser. No. 10/646,632, filed on Aug. 21, 2003, entitled “SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A CORE SCHEMA FOR PROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM”; U.S. patent application Ser. No. 10/646,645, filed on Aug. 21, 2003, entitled “SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM”; U.S. patent application Ser. No. 10/646,575, filed on Aug. 21, 2003, entitled “SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM”; and U.S. patent application Ser. No. 10/646,580, filed on Aug. 21, 2003, entitled “SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM”.

FIELD OF THE INVENTION

The present invention relates generally to the field of information storage and retrieval, and, more particularly, to a storage platform providing change notifications regarding changes in stored information.

BACKGROUND OF THE INVENTION

In many computer systems, the storage and retrieval of information for and by computer applications is handled by one or more central storage systems. For example, one type of storage system commonly used in personal computers is a file-folder-and-directory-based system, also termed a “file system.” Such file systems organize pluralities of files into hierarchies to create an abstraction of the physical organization of the storage medium used to store the files. Generally, such organization into a hierarchy occurs at the operating system level. The files stored generally include the file hierarchy itself (the “directory”) embodied in a special file maintained by the file system. This directory, in turn, maintains a list of entries corresponding to all of the other files in the directory and the nodal location of such files in the hierarchy (herein referred to as the folders).

The use of file system for central storage has several limitations. These may be overcome by using relational database technology as the underpinning of a central storage system, as described in the patent in the patent applications referenced above in the “Cross-Reference” section.

In an application using data stored in a storage system, some activity of the application may be predicated on changes to the data stored in the storage system. For example, an email program may wish to know when a new email message arrives. In certain systems, email messages arrive and are stored on the storage system. When a new message arrives, the email program can then perform any internal processing using the fact that a new email message has arrived or using the content of the email message. For example, some email programs contain rules used to process messages. The application of these rules is triggered, in some cases, by the arrival of a new message. Additionally, there may be user interface changes based on changes to data stored in the storage system. For example, upon the arrival of a new message, an alert may be presented to the user which indicates that a new message has arrived. A list of messages may be refreshed to include the new message.

In view of the foregoing, there is a need for a change notifier that can be used in a database-based storage system and provides for good performance and scalability. The present invention satisfies this need.

SUMMARY OF THE INVENTION

The invention provides for the multiplexing of change notification requests through the issuing of a combined query. In one embodiment, the invention is a storage platform which includes a data store, a database engine which provides a way for interaction to occur with the data store, and an API that provides a way for application programs to issue change notification requests. At least two change notification requests are multiplexed and a combined query is used to query the data store (via a query to the database engine). A data structure, in one embodiment in the form of a table including query parameters, can be used to multiplex queries. The data structure stores the parameters for a change notification request and a query is issued which refers to the data structure to determine what changes are being tracked for notification. When a compatible second change notification request is received, the parameters for that second change notification request is added to the data structure. This alters the query without requiring the reissuing of the query to the database engine. Methods according to the invention can be implemented by instructions stored on a computer-readable medium

Other features and advantages of the invention may become apparent from the following detailed description of the invention and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing summary, as well as the following detailed description of the invention, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the invention, there is shown in the drawings exemplary embodiments of various aspects of the invention; however, the invention is not limited to the specific methods and instrumentalities disclosed. In the drawings:

FIG. 1 is a block diagram representing a computer system in which aspects of the present invention may be incorporated;

FIG. 2 is a block diagram illustrating a computer system divided into three component groups: the hardware component, the hardware/software interface system component, and the application programs component;

FIG. 3 is a block diagram of a computer system according to one embodiment of the invention;

FIGS. 4( a)-4(c) are block diagrams illustrating a parameter table according to one embodiment of the present invention;

FIG. 5 is a flow diagram depicting a method of handling multiple change notification requests according to one embodiment of the invention; and

FIG. 6 is a flow diagram of a method of handling a change notification request according to one embodiment of the invention.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS A. Exemplary Computing Environment

Numerous embodiments of the present invention may execute on a computer. FIG. 1 and the following discussion are intended to provide a brief general description of a suitable computing environment in which the invention may be implemented. Although not required, various aspects of the invention may be described in the general context of computer executable instructions, such as program modules, being executed by a computer, such as a client workstation or a server. Generally, program modules include routines, programs, objects, components, data structures and the like that perform particular tasks or implement particular abstract data types. Moreover, the invention may be practiced with other computer system configurations, including hand held devices, multi processor systems, microprocessor based or programmable consumer electronics, network PCs, minicomputers, mainframe computers and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

As shown in FIG. 1, an exemplary general purpose computing system includes a conventional personal computer 20 or the like, including a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21. The system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system 26 (BIOS), containing the basic routines that help to transfer information between elements within the personal computer 20, such as during start up, is stored in ROM 24. The personal computer 20 may further include a hard disk drive 27 for reading from and writing to a hard disk, not shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to a removable optical disk 31 such as a CD ROM or other optical media. The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively. The drives and their associated computer readable media provide non volatile storage of computer readable instructions, data structures, program modules and other data for the personal computer 20. Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 29 and a removable optical disk 31, it should be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs) and the like may also be used in the exemplary operating environment. Likewise, the exemplary environment may also include many types of monitoring devices such as heat sensors and security or fire alarm systems, and other sources of information.

A number of program modules may be stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or more application programs 36, other program modules 37 and program data 38. A user may enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and pointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite disk, scanner or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor 47, personal computers typically include other peripheral output devices (not shown), such as speakers and printers. The exemplary system of FIG. 1 also includes a host adapter 55, Small Computer System Interface (SCSI) bus 56, and an external storage device 62 connected to the SCSI bus 56.

The personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 49. The remote computer 49 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the personal computer 20, although only a memory storage device 50 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are commonplace in offices, enterprise wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the personal computer 20 is connected to the LAN 51 through a network interface or adapter 53. When used in a WAN networking environment, the personal computer 20 typically includes a modem 54 or other means for establishing communications over the wide area network 52, such as the Internet. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the personal computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

As illustrated in the block diagram of FIG. 2, a computer system 200 can be roughly divided into three component groups: the hardware component 202, the hardware/software interface system component 204, and the applications programs component 206 (also referred to as the “user component” or “software component” in certain contexts herein).

In various embodiments of a computer system 200, and referring back to FIG. 1, the hardware component 202 may comprise the central processing unit (CPU) 21, the memory (both ROM 24 and RAM 25), the basic input/output system (BIOS) 26, and various input/output (I/O) devices such as a keyboard 40, a mouse 42, a monitor 47, and/or a printer (not shown), among other things. The hardware component 202 comprises the basic physical infrastructure for the computer system 200.

The applications programs component 206 comprises various software programs including but not limited to compilers, database systems, word processors, business programs, videogames, and so forth. Application programs provide the means by which computer resources are utilized to solve problems, provide solutions, and process data for various users (machines, other computer systems, and/or end-users).

The hardware/software interface system component 204 comprises (and, in some embodiments, may solely consist of) an operating system that itself comprises, in most cases, a shell and a kernel. An “operating system” (OS) is a special program that acts as an intermediary between application programs and computer hardware. The hardware/software interface system component 204 may also comprise a virtual machine manager (VMM), a Common Language Runtime (CLR) or its functional equivalent, a Java Virtual Machine (JVM) or its functional equivalent, or other such software components in the place of or in addition to the operating system in a computer system. The purpose of a hardware/software interface system is to provide an environment in which a user can execute application programs. The goal of any hardware/software interface system is to make the computer system convenient to use, as well as utilize the computer hardware in an efficient manner.

The hardware/software interface system is generally loaded into a computer system at startup and thereafter manages all of the application programs in the computer system. The application programs interact with the hardware/software interface system by requesting services via an application program interface (API). Some application programs enable end-users to interact with the hardware/software interface system via a user interface such as a command language or a graphical user interface (GUI).

A hardware/software interface system traditionally performs a variety of services for applications. In a multitasking hardware/software interface system where multiple programs may be running at the same time, the hardware/software interface system determines which applications should run in what order and how much time should be allowed for each application before switching to another application for a turn. The hardware/software interface system also manages the sharing of internal memory among multiple applications, and handles input and output to and from attached hardware devices such as hard disks, printers, and dial-up ports. The hardware/software interface system also sends messages to each application (and, in certain case, to the end-user) regarding the status of operations and any errors that may have occurred. The hardware/software interface system can also offload the management of batch jobs (e.g., printing) so that the initiating application is freed from this work and can resume other processing and/or operations. On computers that can provide parallel processing, a hardware/software interface system also manages dividing a program so that it runs on more than one processor at a time.

A hardware/software interface system shell (simply referred to herein as a “shell”) is an interactive end-user interface to a hardware/software interface system. (A shell may also be referred to as a “command interpreter” or, in an operating system, as an “operating system shell”). A shell is the outer layer of a hardware/software interface system that is directly accessible by application programs and/or end-users. In contrast to a shell, a kernel is a hardware/software interface system's innermost layer that interacts directly with the hardware components.

While it is envisioned that numerous embodiments of the present invention are particularly well-suited for computerized systems, nothing in this document is intended to limit the invention to such embodiments. On the contrary, as used herein the term “computer system” is intended to encompass any and all devices capable of storing and processing information and/or capable of using the stored information to control the behavior or execution of the device itself, regardless of whether such devices are electronic, mechanical, logical, or virtual in nature.

B. Change Data Notification

As discussed above, it is useful, for some applications, to have a notification of a change to data stored in the storage system. In at least one storage system using relational database technology, Microsoft Corp.'s WinFS, such notifications are handled by a notification service. In WinFS, an application programming interface (API) allows for such notification requests in WinFS. WinFS API watchers are a set of classes that allow applications to be selectively notified of changes in the WinFS store and provide state information that can be persisted by the application to support suspend/resume scenarios. Through the API an application can create a watcher to watch for specific changes in the storage system. When the change occurs, the watcher raises an event and sends data regarding the change.

A watcher watches for specified changes in the data. In WinFS, data to be stored in the storage system is stored as items. Each item has an associated type. The type of the item is a schema which defines the structure of and properties for the item. In addition, the storage system stores associations between items, known as relationships. An extension can also be associated with an item. Extensions are used to extend a type. An application defines an extension to an item type. For an example, for the “person” type, the schema used by the storage system defines first name, last name, and birth date, etc. as the fields of an item of this type. However, no field for eye color data exists in the person type. If one is needed, then an application can extend the person type by defining an eye color extension. When such an extension is in place, eye color data can be stored in this extension as part of an item of type person.

The watcher class can notify your application of changes to different aspects of WinFS objects, including the following:

Item changes

Item extension changes

Relationship changes

Watchers can act on complicated items. For example, where an item is a hierarchy of other items, the watcher can watch the item and the items in the hierarchy for any changes.

Event data is returned when a watcher raises an event (because it is determined that the change for which notification was requested has occurred). This event data includes data which allows the requesting entity to understand what has occurred, e.g., the identity of the item changed, the type of change (add, modify, delete), etc.

When a watcher raises an event, it sends watcher state data with the event notification. The application can store this state data for later retrieval. Subsequently, the watcher state data can be used to request notification of events for all changes that occurred after the state was generated.

The watcher APIs can be implemented using a command which waits for a result from a query or for a timeout. One such command in the SQL language is “waitfor.” Thus, a watcher which is being requested to look for a change to a certain item ItemToBeWatched might use a query Q(ItemToBeWatched) which only returns when and if a change in ItemToBeWatched occurs, and the watcher would implement a command analogous to the following pseudocode command:

waitfor (Q(ItemToBeWatched))

Appendix A includes actual SQL code which can implement the such a query. The SQL code in Appendix A includes a waitfor query which waits for any item changes to occur in a folder item (folderId). The first portion (“SELECT 1 . . . ”) is a query which returns when an item is added to the folder. The second portion (“SELECT 2 . . . ”) is a query which returns when an item in the folder is modified. The third portion (“SELECT 3 . . . ”) is a query which returns when an item in the folder is deleted.

Thus, change notifications may be accomplished for an application. However, there may be many changes in the data stored in the storage system which are of interest to an application, and so an application may create many watchers to watch different kind of changes. Knowledge about changes in various items, extensions, and relationships may require the use of many change notifiers. However, such queries issued against the database which is at the core of the storage system places a high load on the database server. This high load may cause decreased performance of the storage system by using CPU time and memory. Additionally, scalability is adversely affected; even if a storage system can adequately handle having a number of watchers, it may be impossible to scale up the system.

C. Multiplexing Requests

FIG. 3 is a block diagram of a computer system according to one embodiment of the invention. As shown in FIG. 3, in one embodiment, a data store 310 is implemented on a database engine 320. The data store 310 stores data. In one embodiment, the data store is a relational database. The database engine 320 controls the storage of data in the data store 310. The database engine 320 also accepts queries for data stored in the data store 310, evaluates the queries, and returns data from the data store 310 in response. One such data store 310 and data engine 320 is available from Microsoft Corporation in SQL database products.

The data store 310 and data engine 320 are used as a central storage system for computer system 300. The data store 310 provides the storage for the computer system 300, the database engine 320, among other tasks, provides storage functionality for application programs 306. One way in which functionality is provided by the database engine 320 for application programs 306 is by exposing application programs interfaces (APIs) 315. One of these APIs 315 is watcher API 315(a). The watcher API 315(a) allows a watcher to be requested by an application program 306. The application program 306 can request a watcher in order to request notification whenever a specific change occurs to data in the data store 310. For example, an application program 306 may request to be notified when a document is modified. In the case where data store 310 supports folder trees with a hierarchy that arranges documents under the folder tree, an application program 306 may specify a folder tree, and request notification when any document is modified under that folder tree.

The watcher API 315(a) queries to the database engine 320. The query returns only when the specified change occurs. In one embodiment, the watcher notifies the requesting application only that the change has occurred. In another embodiment, the watcher includes in the change notification to the requesting application program 306 information about the type of change that has occurred. In some embodiments, if no changes occur within a timeout period, the change notification request expires. In one such an embodiment, expiration is not reported to the requesting application program 306. Watcher API 315(a) just resubmits the query request after a query expires. The expiration is, in one embodiment, reported to the requesting application program 306.

In order to provide the advantages of the present invention, some change notification requests are multiplexed. In one embodiment, two or more change notification requests handled by the watcher API 315(a) are multiplexed by storing the information regarding the object of the requests in a data structure. FIGS. 4( a)-4(c) are block diagrams illustrating such a data structure, parameter table 400, according to one embodiment of the present invention. In FIGS. 4( a)-4(c) each entry 410 on the parameter table 400 includes identifying information regarding one change request. Instead of each change notification request resulting in a separate query to the database engine 320, queries can be multiplexed by means of the parameter table 400. FIG. 4( a) illustrates the parameter table 400 after a one change notification request has been received. The first change notification request results in the creation of the parameter table 400 with one initial parameter table entry 410(a) which includes information regarding the change request. A query is then issued which requests that the database engine 320 provide notification of any changes described in any entries 410 of the parameter table 400.

Through the parameter table 400, additional change requests can thus be multiplexed without reissuing the query. FIG. 4( b) illustrates parameter table 400 after two change notification requests have been received and multiplexed. As shown in FIG. 4( b), when an additional change request is received, it is be multiplexed by inserting an additional entry 410(b) into the parameter table 400 which describes the change for which notification has been requested by the additional change request. The query which has been issued to the database engine 320 is unchanged. In FIG. 4( c), which illustrates parameter table 400 after more than two change notification requests have been received, additional entries 410(c) through 410(n) have been inserted into the parameter table 400.

In SQL Server or other relational database systems, tables can be created as a temporary table or a regular table. In one embodiment, the data structure is a temporary table; in another, it is a regular table.

In one embodiment, complex change requests can be described in more than one entry 410 into parameter table 400. In this embodiment, a change request may be associated with more than one entry 410 into the parameter table 400.

An entry 410 into the parameter table will contain information necessary to determine what changes the change notification request is directed towards. This includes information about which items in the data store 310 to watch. Additionally, in various embodiments, the entries 410 may include some or all of:

- identification information for the change notification request (watcher id)
- identification information for the database connection session (session id)
- lower water mark (a time stamp indicating a certain time, changes occurring will only be responsive to the change notification request if they occurred after the lower water mark time); and
- an indication of whether updates, additions, and/or deletions are changes relevant to the change notification request.

The requesters of each change notification request are tracked. When the query returns a result indicating a change responsive to one or more change notification requests, the appropriate requestor(s) are notified of the change that has occurred.

FIG. 5 is a flow diagram depicting a method of handling multiple change notification requests according to one embodiment of the invention. As seen in FIG. 5, an initial change notification request is received 500. In one embodiment, the initial change request is received when a requesting application program 306 invokes a method of an application programming interface (API). As a result of said initial change notification request, at step 510, a query is issued to the database engine 320. This query will return if the change (or one of the changes) indicated in the initial change request has occurred.

At some point following step 500, an additional change notification request is received, step 520. At step 530, the already-issued query is altered. This alteration allows the query to serve both the initial change notification request and the additional change notification requests by returning to indicate a change if any change specified in the initial change request or the additional change request occurs. Further change notification requests may be received and added to the query, as indicated by dashed arrow 540.

While the query is altered in step 530, this alteration does not require resubmission of the query. In one embodiment, the parameter table is modified by inserting rows corresponding to the new request. Because the query includes a reference to the parameter table, as a net result, the existing query will also return changes for the new request.

In one embodiment, the query includes a reference to a data structure such as parameter table 410. Step 530 may, in one such embodiment, be accomplished solely by adding data from the additional change notification request to the data structure. In an alternate embodiment, step 530 may be accomplished by adding data to the change notification request in addition to other actions.

FIG. 6 is a flow diagram of a method of handling a change notification request according to an embodiment of the invention in which multiple data stores exist to which change notifications may be directed, and in which each application or requesting entity has a security context, and in which only requests from entities with the same security context should be multiplexed. As seen in FIG. 6, when a change notification request is received, 600, an examination is made to determine whether a previous request has been made for a change notification to the same store and with the same security context 610. If it has not been, then a new parameter table is created, and a new query is issued, 620. If it has been, then the relevant parameter table is modified 630.

In one embodiment, where the requests are issued by application programs 306 by calling a method of an API, requests are each assigned a request id. When the query returns and indicates that a specific change has occurred, the requests are examined to determine which request or requests the change is responsive to. The information returned by the query is then communicated to the relevant requesting entities by using a callback function provided by the requesting entity in its request.

In one embodiment of the invention, in order to efficiently find rows in the data store 510 which are relevant to a change request, as part of the query, a database index on (session id, watcher id) is created on the parameter table 410. Further, in order to distinguish between evens for different change requests, the watcher id is returned as part of the query result. The results are sorted by watcher id and timestamp. Thus, events for a given change request are consecutive to each other in the result. Appendix B provides a source code listing of the query which implements the multiplexing of requests, in accordance with one embodiment of the present invention. In the store relevant to Appendix B, the data store includes items, extensions, and relationships. In Appendix B, there are nine SELECT queries inside a WAITFOR query. These select statements find change for, in order, monitoring to see if any of the following events have happened which are responsive to a change request: item additions, item modifications, item deletions, extension additions, extension modifications, extension deletions, relationship additions, relationship modifications, and relationship deletions.

D. Conclusion

As the foregoing illustrates, the present invention is directed to a storage platform for organizing, searching, and sharing data. The storage platform of the present invention extends and broadens the concept of data storage beyond existing file systems and database systems, and is designed to be the store for all types of data, including structured, non-structured, or semi-structured data, such as relational (tabular) data, XML, and a new form of data called Items. Through its common storage foundation and schematized data, the storage platform of the present invention enables more efficient application development for consumers, knowledge workers and enterprises. It offers a rich and extensible application programming interface that not only makes available the capabilities inherent in its data model, but also embraces and extends existing file system and database access methods. It is understood that changes may be made to the embodiments described above without departing from the broad inventive concepts thereof. Accordingly, the present invention is not limited to the particular embodiments disclosed, but is intended to cover all modifications that are within the spirit and scope of the invention as defined by the appended claims.

As is apparent from the above, all or portions of the various systems, methods, and aspects of the present invention may be embodied in the form of program code (i.e., instructions). This program code may be stored on a computer-readable medium, such as a magnetic, electrical, or optical storage medium, including without limitation a floppy diskette, CD-ROM, CD-RW, DVD-ROM, DVD-RAM, magnetic tape, flash memory, hard disk drive, or any other machine-readable storage medium, wherein, when the program code is loaded into and executed by a machine, such as a computer or server, the machine becomes an apparatus for practicing the invention. The present invention may also be embodied in the form of program code that is transmitted over some transmission medium, such as over electrical wiring or cabling, through fiber optics, over a network, including the Internet or an intranet, or via any other form of transmission, wherein, when the program code is received and loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention. When implemented on a general-purpose processor, the program code combines with the processor to provide a unique apparatus that operates analogously to specific logic circuits.

APPENDIX A

Waitfor(

	(SELECT 1 as eventType, t.TargetItemId, t._CreationLocalTS
	as timeStamp, CONVERT(bigint, min_active_rowversion( )) as
	lwm, t._PathHandle
	[System.Storage.Store].[Tombstone!ItemsInDomain](@folderId)

t

WHERE

	(@ItemType IS NULL) OR
	([System.Storage.Store].[IsOfItemType](t.TargetItemId,
	@ItemType) = 1)) AND
	t._TombstoneStatus = 0 AND
	t._CreationLocalTS >= @LowWatermark AND
	t._CreationLocalTS not IN
	(select ts From
	tempdb.dbo.[System.Storage.Watcher.Duplicates] d
	WHERE d.SessionId = @SqlSessionId AND d.ItemId =
	t.TargetItemId AND d.ExtOrRelId = ‘00000000-0000-
	0000-0000-000000000000’)

	UNION ALL
	SELECT 2 as eventType, t.TargetItemId,
	i._ChangeTrackingInfo.LastUpdateLocalTS as timeStamp,
	CONVERT(bigint, min_active_rowversion( )) as lwm,
	t._PathHandle
	[System.Storage.Store].[Tombstone!ItemsInDomain](@folderId)

t

INNER JOIN [System.Storage.Store].[Master!Item] i ON

t.TargetItemId = i.ItemId

WHERE

	((@ItemType IS NULL) OR
	([System.Storage.Store].[IsOfItemType](t.TargetItemId,
	@ItemType) = 1)) AND
	i._ChangeTrackingInfo.LastUpdateLocalTS >=

@LowWatermark AND

	i._ChangeTrackingInfo.LastUpdateLocalTS >
	i._ChangeTrackingInfo.CreationLocalTS AND
	i._ChangeTrackingInfo.LastUpdateLocalTS NOT IN

	(select ts From
	tempdb.dbo.[System.Storage.Watcher.Duplicates] d
	WHERE d.SessionId = @SqlSessionId AND d.ItemId =
	i.ItemId AND d.ExtOrRelId = ‘00000000-0000-0000-
	0000-000000000000’)

	UNION ALL
	SELECT 3 as eventType, t.TargetItemId,
	t._LastUpdateLocalTS as timeStamp, CONVERT(bigint,
	min_active_rowversion( )) as lwm, t._PathHandle
	FROM
	[System.Storage.Store].[Tombstone!ItemsInDomain](@folderId)

t

WHERE

	((@ItemType IS NULL) OR
	([System.Storage.Store].[IsOfItemType](t.TargetItemId,
	@ItemType) = 1)) AND
	t._LastUpdateLocalTS>= @LowWatermark AND
	t._TombstoneStatus <> 0 AND
	t._LastUpdateLocalTS not IN
	(select ts From
	tempdb.dbo.[System.Storage.Watcher.Duplicates] d WHERE
	d.SessionId = @SqlSessionId AND d.ItemId = t.TargetItemId
	AND d.ExtOrRelId = ‘00000000-0000-0000-0000-000000000000’)
	)ORDER BY timeStamp ASC

), timeout 30000

APPENDIX B

WAITFOR(( SELECT w.WatcherId, 1 as eventType, t.TargetItemId,
NULL, t._CreationLocalTS as timeStamp, CONVERT(bigint,
min_active_rowversion( )) as lwm, t._PathHandle
FROM tempdb.dbo.[System.Storage.Watcher.Parameters] w CROSS
APPLY
[System.Storage.Store].[Tombstone!ItemsInDomain](w.DomainRoot) t
WHERE
w.SessionId = @SqlSessionId AND
w.WatchAdd = 1 AND
w.WatcherDepth = 3 AND
(w.WatchItem = 1) AND ((w.ItemType IS NULL) OR
([System.Storage.Store].[IsOfItemType](t.TargetItemId,
w.ItemType) = 1)) AND
t._TombstoneStatus = 0 AND
t._CreationLocalTS >= w.LowWatermark AND
t._CreationLocalTS not IN
(select ts From tempdb.dbo.[System.Storage.Watcher.Duplicates]
d WHERE d.SessionId = @SqlSessionId AND WatcherId = w.WatcherId
AND d.ItemId = t.TargetItemId AND d.ExtOrRelId = ‘00000000-
0000-0000-0000-000000000000’)
UNION ALL
SELECT w.WatcherId, 2 as eventType, t.TargetItemId, NULL,
i._ChangeTrackingInfo.LastUpdateLocalTS as timeStamp,
CONVERT(bigint, min_active_rowversion( )) as lwm, t._PathHandle
FROM tempdb.dbo.[System.Storage.Watcher.Parameters] w CROSS
APPLY
[System.Storage.Store].[Tombstone!ItemsInDomain](w.DomainRoot) t
INNER JOIN [System.Storage.Store].[Master!Item] i ON
t.TargetItemId = i.ItemId
WHERE
w.SessionId = @SqlSessionId AND
w.WatchUpdate = 1 AND
w.WatcherDepth = 3 AND
(w.WatchItem = 1) AND ((w.ItemType IS NULL) OR
([System.Storage.Store].[IsOfItemType](t.TargetItemId,
w.ItemType) = 1)) AND
i._ChangeTrackingInfo.LastUpdateLocalTS >= w.LowWatermark AND
i._ChangeTrackingInfo.LastUpdateLocalTS >
i._ChangeTrackingInfo.CreationLocalTS AND
i._ChangeTrackingInfo.LastUpdateLocalTS NOT IN
(select ts From tempdb.dbo.[System.Storage.Watcher.Duplicates]
d WHERE d.SessionId = @SqlSessionId AND WatcherId = w.WatcherId
AND d.ItemId = i.ItemId AND d.ExtOrRelId = ‘00000000-0000-0000-
0000-000000000000’)
UNION ALL
SELECT w.WatcherId, 3 as eventType, t.TargetItemId, NULL,
t._LastUpdateLocalTS as timeStamp, CONVERT(bigint,
min_active_rowversion( )) as lwm, t._PathHandle
FROM tempdb.dbo.[System.Storage.Watcher.Parameters] w CROSS
APPLY
[System.Storage.Store].[Tombstone!ItemsInDomain](w.DomainRoot) t
WHERE
w.SessionId = @SqlSessionId AND
w.WatchDelete = 1 AND
w.WatcherDepth = 3 AND
(w.WatchItem = 1) AND ((w.ItemType IS NULL) OR
([System.Storage.Store].[IsOfItemType](t.TargetItemId,
w.ItemType) = 1)) AND
t._LastUpdateLocalTS>= w.LowWatermark AND
t._TombstoneStatus <> 0 AND
t._LastUpdateLocalTS not IN
(select ts From tempdb.dbo.[System.Storage.Watcher.Duplicates]
d WHERE d.SessionId = @SqlSessionId AND WatcherId = w.WatcherId
AND d.ItemId = t.TargetItemId AND d.ExtOrRelId = ‘00000000-
0000-0000-0000-000000000000’)
UNION ALL
SELECT w.WatcherId, 4 as eventType, e.ItemId, e.TypeFamilyId,
e._ChangeTrackingInfo.CreationLocalTS as timeStamp,
CONVERT(bigint, min_active_rowversion( )) as lwm, t._PathHandle
FROM tempdb.dbo.[System.Storage.Watcher.Parameters] w CROSS
APPLY
[System.Storage.Store].[Tombstone!ItemsInDomain](w.DomainRoot) t
INNER JOIN [System.Storage.Store].[Master!Extension] e ON
t.TargetItemId = e.ItemId
WHERE w.SessionId = @SqlSessionId AND w.WatchAdd = 1 AND
w.WatcherDepth = 3 AND
(w.WatchExtension = 1) AND ((w.ExtensionType IS NULL) OR
([System.Storage.Store].[IsOfExtensionType](e.ItemId,
e.TypeFamilyId, w.ExtensionType) = 1)) AND
e._ChangeTrackingInfo.CreationLocalTS >= w.LowWatermark AND
e._ChangeTrackingInfo.CreationLocalTS not IN
(select ts From tempdb.dbo.[System.Storage.Watcher.Duplicates]
d WHERE d.SessionId = @SqlSessionId AND WatcherId = w.WatcherId
AND d.ItemId = e.ItemId AND d.ExtOrRelId = e.TypeFamilyId)
UNION ALL
SELECT w.WatcherId, 5 as eventType, e.ItemId, e.TypeFamilyId,
e._ChangeTrackingInfo.LastUpdateLocalTS as timeStamp,
CONVERT(bigint, min_active_rowversion( )) as lwm, t._PathHandle
FROM tempdb.dbo.[System.Storage.Watcher.Parameters] w CROSS
APPLY
[System.Storage.Store].[Tombstone!ItemsInDomain](w.DomainRoot) t
INNER JOIN [System.Storage.Store].[Master!Extension] e ON
t.TargetItemId = e.ItemId
WHERE
w.SessionId = @SqlSessionId AND
w.WatchUpdate = 1 AND
w.WatcherDepth = 3 AND
(w.WatchExtension = 1) AND ((w.ExtensionType IS NULL) OR
([System.Storage.Store].[IsOfExtensionType](e. ItemId,
e.TypeFamilyId, w.ExtensionType) = 1)) AND
e._ChangeTrackingInfo.LastUpdateLocalTS >= w.LowWatermark AND
e._ChangeTrackingInfo.LastUpdateLocalTS >
e._ChangeTrackingInfo.CreationLocalTS AND
e._ChangeTrackingInfo.LastUpdateLocalTS not IN
(select ts From tempdb.dbo.[System.Storage.Watcher.Duplicates]
d WHERE d.SessionId = @SqlSessionId AND WatcherId = w.WatcherId
AND d.ItemId = e.ItemId AND d.ExtOrRelId = e.TypeFamilyId)
UNION ALL
SELECT w.WatcherId, 6 as eventType, e.ItemId, e.TypeFamilyId,
e._ChangeTrackingInfo.LastUpdateLocalTS as timeStamp,
CONVERT(bigint, min_active_rowversion( )) as lwm, t._PathHandle
FROM tempdb.dbo.[System.Storage.Watcher.Parameters] w CROSS
APPLY
[System.Storage.Store].[Tombstone!ItemsInDomain](w.DomainRoot) t
INNER JOIN [System.Storage.Store].[Tombstone!Extension] e ON
t.TargetItemId = e.ItemId
WHERE
w.SessionId = @SqlSessionId AND
w.WatchDelete = 1 AND
w.WatcherDepth = 3 AND
(w.WatchExtension = 1) AND ((w.ExtensionType IS NULL) OR
([System.Storage.Store].[IsOfExtensionType](e.ItemId,
e.TypeFamilyId, w.ExtensionType) = 1)) AND
e._TombstoneStatus <>0 AND
e._ChangeTrackingInfo.LastUpdateLocalTS >= w.LowWatermark AND
e._ChangeTrackingInfo.LastUpdateLocalTS not IN
(select ts From tempdb.dbo.[System. Storage.Watcher.Duplicates]
d WHERE d.SessionId = @SqlSessionId AND WatcherId = w.WatcherId
AND d.ItemId = e.ItemId AND d.ExtOrRelId = e.TypeFamilyId)
UNION ALL
SELECT w.WatcherId, 7 as eventType, r.SourceItemId,
r.relationshipId, r.ChangeTrackingInfo.CreationLocalTS as
timeStamp, CONVERT(bigint, min_active_rowversion( )) as lwm,
t._PathHandle
FROM tempdb.dbo.[System.Storage.Watcher.Parameters] w CROSS
APPLY
[System.Storage.Store].[Tombstone!ItemsInDomain](w.DomainRoot) t
INNER JOIN [System.Storage.Store].[Master!Relationship] r ON
t.TargetItemId = r.SourceItemId
WHERE
w.SessionId = @SqlSessionId AND
w.WatchAdd = 1 AND
w.WatcherDepth = 3 AND
(w.WatchRelation = 1) AND ((w.RelationshipType IS NULL) OR
([System.Storage.Store].[IsOfRelationshipType](r.SourceItemId,
r.relationshipId, w.RelationshipType) = 1)) AND
r._ChangeTrackingInfo.CreationLocalTS >= w.LowWatermark AND
r._ChangeTrackingInfo.CreationLocalTS not IN
(select ts From tempdb.dbo.[System.Storage.Watcher.Duplicates]
d WHERE SessionId = @SqlSessionId AND WatcherId = w.WatcherId
AND d.ItemId = r.SourceItemId AND d.ExtOrRelId =
r.RelationshipId)
UNION ALL
SELECT w.WatcherId, 8 as eventType, r.SourceItemId,
r.relationshipId, r._ChangeTrackingInfo.LastUpdateLocalTS as
timeStamp, CONVERT(bigint, min_active_rowversion( )) as lwm,
t._PathHandle
FROM tempdb.dbo.[System.Storage.Watcher.Parameters] w CROSS
APPLY
[System.Storage.Store].[Tombstone!ItemsInDomain](w.DomainRoot) t
INNER JOIN [System.Storage.Store].[Master!Relationship] r ON
t.TargetItemId = r.SourceItemId
WHERE
w.SessionId = @SqlSessionId AND
w.WatchUpdate = 1 AND
w.WatcherDepth = 3 AND
(w.WatchRelation = 1) AND ((w.RelationshipType IS NULL) OR
([System.Storage.Store].[IsOfRelationshipType](r.SourceItemId,
r.relationshipId, w.RelationshipType) = 1)) AND
r._ChangeTrackingInfo.LastUpdateLocalTS >= w.LowWatermark AND
r._ChangeTrackingInfo.LastUpdateLocalTS >
r._ChangeTrackingInfo.CreationLocalTS AND
r._ChangeTrackingInfo.LastUpdateLocalTS not IN
(select ts From tempdb.dbo.[System.Storage.Watcher.Duplicates]
d WHERE SessionId = @SqlSessionId AND WatcherId = w.WatcherId
AND d.ItemId = r.SourceItemId AND d.ExtOrRelId =
r.RelationshipId)
UNION ALL
SELECT w.WatcherId, 9 as eventType, r.SourceItemId,
r.relationshipId, r._ChangeTrackingInfo.LastUpdateLocalTS as
timeStamp, CONVERT(bigint, min_active_rowversion( )) as lwm,
t._PathHandle
FROM tempdb.dbo.[System.Storage.Watcher.Parameters] w CROSS
APPLY
[System.Storage.Store].[Tombstone!ItemsInDomain](w.DomainRoot) t
INNER JOIN [System.Storage.Store].[Tombstone!Relationship] r ON
t.TargetItemId = r.SourceItemId
WHERE w.SessionId = @SqlSessionId AND
w.WatchDelete = 1 AND
w.WatcherDepth = 3 AND
(w.WatchRelation = 1) AND ((w.RelationshipType IS NULL) OR
([System.Storage.Store].[IsOfRelationshipType] (r.SourceItemId,
r.relationshipId, w.RelationshipType) = 1)) AND
r._TombstoneStatus <>0 AND
r._ChangeTrackingInfo.LastUpdateLocalTS >= w.LowWatermark AND
r._ChangeTrackingInfo.LastUpdateLocalTS not IN
(select ts From tempdb.dbo.[System.Storage.Watcher.Duplicates]
d WHERE SessionId = @SqlSessionId AND WatcherId = w.WatcherId
AND d.ItemId = r.SourceItemId AND d.ExtOrRelId =
r.RelationshipId)
)ORDER BY WatcherId, timeStamp ASC
), timeout 30000

Claims

1. A storage platform comprising:

a database engine;

a data store implemented on the database engine for storing data therein;

an application programming interface that enables application programs to issue requests for notification of a change to one or more specified elements stored in the data store; and

a data structure comprising a plurality of parameter tables, each one of the plurality of parameter tables configured to respectively store information regarding requests from entities with a same security context, wherein:

requests from at least two entities subject to having the same security context are multiplexed to form a combined query of the database engine;

a first change notification request from a first entity of said at least two entities has a first security context for accessing said data store;

a second change notification request from a second entity of said at least two entities has a second security context for accessing said data store; and

said first change notification request and said second change notification request are directed to a same parameter table of said plurality of parameter tables.

2. The storage platform of claim 1, wherein the data structure stores information identifying one or more elements of the data stored in the data store as a subject of at least one of said multiplexed requests, and wherein said combined query references said data structure.

3. The storage platform of claim 2, wherein said data structure stores, for each such element of the data identified as the subject of at least one of said multiplexed requests, information identifying a type of change to said subject element for which notification has been requested.

4. The storage platform of claim 2, where said combined query comprises reference information identifying said data structure.

5. The storage platform of claim 2, wherein if an additional request for notification of a change to one or more specified elements stored in the data store is received, additional information is added to said data structure, said additional information identifying one or more elements of the data stored in the data store as the subject of said additional request.

6. The storage platform of claim 2, wherein said data structure further stores, for each of said multiplexed requests, requestor information identifying a requestor for said multiplexed request, and wherein, when a change is returned by said combined query relevant to one of said multiplexed requests, said requestor information is used to return information to a corresponding requestor.

7. The storage platform of claim 1, where said storage platform implements a security scheme to govern access to the data store, and wherein said multiplexing of requests occurs only for requests which are similar with respect to their access available to said data store under said security scheme.

8. The storage platform of claim 1,

further comprising at least one additional data store;

wherein said application programming interface enables application programs to issue requests for notification of a change to one or more specified elements stored in any of said data stores; and

wherein said multiplexing of requests occurs only for requests directed at the same data store.

9. A computer-implemented method for handling a first change notification request for notification of a first change to data in a data store and a second change notification request for notification of a second change to data in a data store, comprising:

receiving via the computer, said first change notification request;

determining that said first change notification has a first security context for accessing said data store;

storing information regarding the first change notification request as a first parameter entry in a first parameter table of a data structure;

submitting a query to said data store, said query calculated to indicate an occurrence of said first change;

receiving said second change notification request;

determining that said second change notification request has a second security context for accessing said data store;

examining said second change notification request for determining: a) that the request is directed to the first parameter table and b) that the second security context is similar to the first security context; and

subject to said second change notification request a) being directed to the first parameter table and b) having said second security context similar to the first security context:

storing information regarding the second change notification request as a second parameter entry in the first parameter table of the data structure; and

altering said previously submitted query via access to said data structure without resubmission of said previously submitted query, so that said previously submitted query is thereafter calculated to indicate an occurrence of at least one of said first change or said second change;

else, when said second change notification request is a) not directed to the first parameter table or b) has said second security context different than said first security context:

storing information regarding the second change notification request as a first parameter entry in a second parameter table of the data structure; and

submitting a new query independent of said previously submitted query, the new query calculated to indicate an occurrence of said second change.

10. The method of claim 9, where said previously submitted query comprises a reference to the first parameter table, where said first parameter table comprises at least one query parameter describing said first change for notification, and where said step of altering said query comprises adding at least one query parameter concerning said second change to said first parameter table.

11. The method of claim 9, where said previously submitted query comprises a reference to the first parameter table, where said first parameter table comprises at least one query parameter describing said first change for notification, and where said step of altering said query consists of adding at least one query parameter concerning said second change to said first parameter table.

12. A computer-readable storage medium having instructions stored thereon for causing a computer to perform a method of handling a first change notification request for notification of a first change to data in a data store and a second change notification request for notification of a second change to data in a data store, said method comprising:

receiving said first change notification request;

receiving said second change notification request;

determining that said second change notification has a second security context for accessing said data store;

13. The computer-readable storage medium of claim 12, where said previously submitted query comprises a reference to said first parameter table, where said first parameter table comprises at least one query parameter describing said first change for notification, and where said step of altering said query comprises adding at least one query parameter concerning said second change to said first parameter table.

14. The computer-readable storage medium of claim 12, where said previously submitted query comprises a reference to said first parameter table, where said first parameter table comprises at least one query parameter describing said first change for notification, and where said step of altering said query consists of adding at least one query parameter concerning said second change to said first parameter table.