Performing event notification in a database having a distributed web cluster

FIELD OF THE INVENTION

This invention relates generally to distributed computing systems, and more particularly to a method and apparatus for performing event notification in a database having a distributed web cluster.

BACKGROUND OF THE INVENTION

Modern computerized search systems can contain vast amounts of data. In order to be useful, they must return search results to a user in a reasonable amount of time. One application for computerized search systems is that of finding geographic entities such as an address, street, area, point, businesses, or list of cities that are located near a given starting point. For example, with a system containing a database of homes and businesses with corresponding addresses or geographical locations within a city, a user may want to locate banks, automated teller machines (ATMs), or restaurants which are close to a specific address or business within the city. Because the user may be waiting for the results of the search in real-time, the search results must be returned very quickly. In addition, the results should preferably be presented in an ordered format according to the usefulness to the user. For example, some businesses might have a sale or special offering which should be presented to the user before other businesses which do not have a sale or special.

To improve the access speed to information through public data networks such as the Internet, database information may be copied or “mirrored” across one or more physically distributed servers, known as web clusters. The servers may be widely separated geographically and may contain multiple independent data paths which are separated from those of other servers.

With a distributed data network having multiple data servers, there is a problem in updating and maintaining consistent information on all of the servers. For example, if new information is uploaded to one server, the information must also be distributed to and synchronized with the other mirror servers within the network. In some prior art systems, update information is broadcast to the mirror servers once a day. While this approach may be acceptable for information which does not generally change very rapidly, such as static links to web sites, it leads to server inconsistencies and unacceptable delays for time-critical information such as stock quotes or news reports.

Therefore, there is a need for a way to update time-critical information in a database having multiple servers in a distributed web cluster.

SUMMARY OF THE INVENTION

The present invention provides a method and apparatus for performing event notification in a system having a distributed web cluster. A change of state is provided to the system. A state change table is updated in the system with the provided change of state. The change of state is propagated from the state change table to the web cluster, through polling, broadcast, or other methods. The web cluster is synchronized to reflect the state change.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and may be better understood by referring to the following description in conjunction with the accompanying drawings, in which like references indicate similar elements and in which:

FIG. 1 is a system diagram which shows a computer hardware environment compatible with the present invention;

FIG. 2 is a system diagram which shows a distributed web cluster environment compatible with the present invention;

FIG. 3 is an internal diagram of a web server compatible with the present invention;

FIG. 4 is an internal diagram of an event notification system compatible with the present invention;

FIG. 5 is a flowchart which shows a method for performing event notification in a database having a distributed web cluster compatible with the present invention.

DESCRIPTION OF AN EMBODIMENT OF THE PRESENT INVENTION

In the following description of an embodiment, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration a specific embodiment in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present invention. A preferred embodiment of the present invention, described below, enables a remote computer system user to execute a software application on a network file server.

In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate description.

The present invention provides a method and apparatus for performing event notification in a system having a distributed web cluster. A change of state is provided to the system. A state change table is updated in the system with the provided change of state. The change of state is propagated from the state change table to the web cluster, through polling, broadcast, or other methods. The web cluster is synchronized to reflect the state change. Any type of message or event may be sent to the distributed web including but not limited to state information, lock out commands, additions, modifications, or deletions of information content, web pages, banner ads, or calendar events.

FIG. 1 illustrates one embodiment of a computer system <b>100</b> which implements the principles of the present invention. Computer system <b>100</b> comprises a processor <b>105</b>, a storage device <b>110</b>, and a bus <b>115</b>. The processor <b>105</b> is coupled to the storage device <b>110</b> by the bus <b>115</b>. In addition, a number of user input/output devices, such as a keyboard <b>120</b> and a display <b>125</b>, are also coupled to the bus <b>115</b>. The processor <b>105</b> represents a central processing unit of any type of architecture, such as CISC, RISC, VLIW, or hybrid architecture. In addition, the processor <b>105</b> could be implemented on one or more chips. The storage device <b>110</b> represents one or more mechanisms for storing data. For example, the storage device <b>110</b> may include read only memory (ROM), random access memory (RAM), magnetic disk storage mediums, optical storage mediums, flash memory devices, and/or other machine-readable mediums. The bus <b>115</b> represents one or more buses (e.g., AGP, PCI, ISA, X-Bus, VESA, etc.) and bridges (also termed as bus controllers). While this embodiment is described in relation to a single processor computer system, the invention could be implemented in a multi-processor computer system.

In addition to other devices, one or more of a network <b>130</b>, a TV broadcast signal receiver <b>131</b>, a fax/modem <b>132</b>, a digitizing unit <b>133</b>, a sound unit <b>134</b>, and a graphics unit <b>135</b> may optionally be coupled to bus <b>115</b>. The network <b>130</b> and fax modem <b>132</b> represent one or more network connections for transmitting data over a machine readable media (e.g., carrier waves). The digitizing unit <b>133</b> represents one or more devices for digitizing images (i.e., a scanner, camera, etc.). The sound unit <b>134</b> represents one or more devices for inputting and/or outputting sound (e.g., microphones, speakers, magnetic storage devices, optical storage devices, etc.). The graphics unit <b>135</b> represents one or more devices for generating <b>3</b>-D images (e.g., graphics card).

FIG. 1 also illustrates that the storage device <b>110</b> has stored therein data <b>136</b> and software <b>137</b>. Data <b>136</b> represents data stored in one or more of the formats described herein. Software <b>137</b> represents the necessary code for performing any and/or all of the techniques described with reference to FIGS. 3-6. It will be recognized by one of ordinary skill in the art that the storage device <b>110</b> preferably contains additional software (not shown), which is not necessary to understanding the invention.

FIG. 1 additionally illustrates that the processor <b>105</b> includes decode unit <b>140</b>, a set of registers <b>141</b>, and execution unit <b>142</b>, and an internal bus <b>143</b> for executing instructions. It will be recognized by one of ordinary skill in the art that the processor <b>105</b> contains additional circuitry, which is not necessary to understanding the invention. The decode unit <b>140</b>, registers <b>141</b> and execution unit <b>142</b> are coupled together by internal bus <b>143</b>. The decode unit <b>140</b> is used for decoding instructions received by processor <b>105</b> into control signals and/or microcode entry points. In response to these control signals and/or microcode entry points, the execution unit <b>142</b> performs the appropriate operations. The decode unit <b>140</b> may be implemented using any number of different mechanisms (e.g., a look-up table, a hardware implementation, a PLA, etc.). While the decoding of the various instructions is represented herein by a series of if/then statements, it is understood that the execution of an instruction does not require a serial processing of these if/then statements. Rather, any mechanism for logically performing this if/then processing is considered to be within the scope of the implementation of the invention.

The registers <b>141</b> represent a storage are on processor <b>105</b> for storing information, including control/status information, integer data, floating point data, and packed data. It will be understood by one of ordinary skill in the art that one aspect of the invention is the described instruction set for operating on packed data. According to this aspect of the invention, the storage area used for storing the packed data is not critical. The term data processing system is used herein to refer to any machine for processing data, including the computer systems(s) described with reference to FIG. <b>1</b>.

As shown in FIG. 2, the present invention is compatible with a distributed database including one or more web clusters. Multiple web clusters <b>201</b>, <b>203</b> may each contain multiple web servers <b>205</b>, <b>207</b>. Each of the web servers <b>205</b>, <b>207</b> have access to a centralized state change table <b>209</b>, <b>211</b>. The state change table <b>209</b>, <b>211</b> is used to synchronize the web servers <b>205</b>, <b>207</b> with each other and with those within each of the web clusters <b>201</b>, <b>203</b>. In one embodiment of the present invention, the web servers <b>205</b>, <b>207</b> determine that there is a new event or change of state by periodically polling the state change table <b>209</b>, <b>211</b>. It will be recognized by one of ordinary skill in the art that methods of determining a new event or change of state other than polling are compatible with the present invention, such as checking the state change table for a new event each time a request for information is performed by the web server <b>205</b>, <b>209</b>, or sending an event notification trigger message from the state change table <b>209</b>, <b>211</b> to the web server <b>205</b>, <b>209</b> each time a new event is added to the state change table <b>209</b>, <b>211</b>.

As shown in FIG. 3, a web server <b>301</b> typically implements a memory cache to hold the most frequently accessed information in memory. This allows the web server <b>301</b> to more quickly retrieve the information than if it was stored on a fixed storage device such as a hard disk drive or CD ROM drive. However, when an update is made to the information within the database contained on the fixed storage device, the web server <b>301</b> must flush the information contained in the memory cache in order eliminate possible inconsistencies between memory and disk. Without first flushing the cache, any update to the information within the database will not be visible when external requests for information are made by users and other servers. In one embodiment of the present invention, separate memory caches are used for banner ads <b>305</b> and calendar events <b>307</b>. When information such as a banner ad or a page content item is modified or added through the event notification system <b>303</b>, each production web server <b>301</b> automatically flushes its banner ad memory cache <b>305</b> or calendar events cache <b>307</b> accordingly. It will be recognized by one of ordinary skill in the art that many other well-known memory cache structures, such as a single set associative cache or other multiple caches implementing any one of a number of cache algorithms such as a least recently used (LRU) algorithm, may be used with the present invention without loss of generality.

FIG. 4 describes an event notification structure compatible with the present invention. An event notification system <b>401</b> preferably implements a periodic watch module <b>403</b>, a notification list <b>405</b>, and a dispatch list <b>411</b>. The watch module <b>403</b> monitors the state change table <b>407</b>, <b>409</b> to determine any change in state or any new notification message. The notification list <b>405</b> records notification events in state change table <b>407</b>, <b>409</b>. The dispatch list <b>411</b> is used for transmitting and synchronizing banner ads through the banner ad memory cache <b>413</b> or the calendar events cache <b>415</b> accordingly.

In one embodiment of the present invention, the state change table <b>209</b>, <b>211</b>, <b>407</b>, <b>409</b> is updated as described below.

1. Set up a configuration file for each application which points to an eventnotify table.

2. Create the eventnotify table on a database server.

In one embodiment of the present invention, an example configuration file may contain the following information:

# Event notification (e.g. page content flush, banner ad flush). By using SQLServerName for EventNotifyServerName,

# we automatically use development\production values without requiring an explicit local.txt entry.

!EventNotifyServerName: XXSQLSERVERNAMEXX

!EventNotifyName: abi

!EventNotifyTable: abi.eventnotify

In one embodiment of the present invention, an example core configuration file may contain the following information:

# Event notification (e.g. page content flush, banner ad flush), also requires setting of

# EventNotifyServerName, EventNotifyName, and EventNotifyTable.

# To disable event notification, set EventNotifyPollingInterval to zero

# or unset any of the other event notify settings.

!EventNotifyPollingInterval: 1

In the above example, the polling interval is set to one minute. It will be recognized that it is also possible to eliminate polling through the use of database triggers. The application program interface (API), described below, can remain the same even if polling is eliminated in the Core implementation.

In one embodiment of the present invention, event notification without polling may be implemented as described below:

\\ Generic, application-generated event notification virtual void eventNotify(const char*name, const char*argument);

This method may be called whenever an event happens. The name of the event is a string that defines the event, and the second argument is a modifier for the event. The set of event strings may be defined as constants in a header file.

In one embodiment of the present invention, an event is invoked as described below:

\\ Generic, application-generated event notification. Use eventNotify for this machine only,

\\ and productionNotify for all machines.

void eventNotify(const char*name, const char*argument=“ ”);

void productionNotify(const char*name, const char*argument=“ ”)

It will be recognized that eventNotify only distributes the event for the local server. It is also possible to use productionnotify, which sends the event to all servers. After a call to productionNotify, all servers will preferably act upon the event within one minute, assuming that there is load on the server and the timeout is checked after each request. For example, banner ads should be flushed whenever a banner ad is modified or added. In one embodiment of the invention, this is implemented as described below:

\\ Flush banner ads theContextApp.productionNotify(EVENT_FLUSHBANNERAD);

In the banner ad server, which may preferably be a persistent object, a flush banner event is preferably monitored using a virtual C++ method and the cache flushes in response as described below:

void

BannerAdMgr::eventNotify(const char*name, const char*argument)

{

if (!strcmp(name, EVENT_FLUSHBANNERAD)) { flushContext( );

}

}

In one embodiment of the present invention, a method for performing event notification in a database having a distributed web cluster is shown in FIG. <b>5</b>. At step <b>501</b>, the event notification system queries the state change table for a maximum event serial number. This gives the last event generated prior to startup. At step <b>503</b>, the state change table is queried for any events whose serial number exceeds that of the last processed event. This gives any new events since the last check. If at step <b>505</b> there are no events, control passes to step <b>509</b>, where the system waits for a fixed amount of time and then returns control to step <b>503</b>. Otherwise, at step <b>507</b> each new event is dispatched to modules listed in a registry and control passes to step <b>509</b>.

While the invention is described in terms of preferred embodiments in a specific system environment, those of ordinary skill in the art will recognize that the invention can be practiced, with modification, in other and different hardware and software environments within the spirit and scope of the appended claims.