Patent Publication Number: US-10783142-B2

Title: Efficient data retrieval in staged use of in-memory cursor duration temporary tables

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS; BENEFIT CLAIM 
     This application claims the benefit of Provisional Application 62/245,869, filed Oct. 23, 2015, the entire contents of which is hereby incorporated by reference as if fully set forth herein, under 35 U.S.C. § 119(e). 
    
    
     FIELD OF THE INVENTION 
     The present invention relates to processing queries in a multi-node database system. Specifically, the present invention relates to retrieving data from temporary tables to process multi-stage queries. 
     BACKGROUND 
     In a clustered database system, multiple “nodes” may have access to the same on-disk copy of a database. Typically, each node is a computing device with its own local memory and processors that are running one or more database instances. The database server instances on each of the nodes may receive queries to access the data. A query coordinator may assign work to be performed for the query among multiple slave processes running on the nodes in the database system, in order to process the query in parallel. 
     A complex query may be executed in multiple stages. During execution of the query, results generated by a stage may be used by another, subsequent stage. These results are temporarily stored in a table referred to herein as a “cursor duration temporary table.” When a database system receives a query, it generates an execution plan for executing the query. If cursor duration temporary tables are required, then execution plan operations are written to refer to one or more temporary tables. A temporary table may be stored on a shared disk or in memory of one or more nodes so that they can be accessed in later stages. 
     Various approaches for storing cursor duration temporary tables, or portions thereof, into volatile memory to speed up query processing are described in U.S. patent application Ser. No. 15/268,519, entitled “In-Memory Cursor Duration Temp Tables,” filed Sep. 16, 2016, referred to herein as the “In-Memory” application, the contents of which are incorporated herein in its entirety. 
     According to the approaches described in the In-Memory application, a portion of memory in each node of a clustered database system is allocated for storing in-memory cursor duration temporary tables. A slave process may be assigned one or more memory segments from the portion of memory for writing temporary table data. Any slave process running on the same node may read from the one or more memory segments. Nodes in the cluster may have access to one or more disks, which may be used to store temporary table data that do not fit in memory. One or more disk segments may be assigned to a slave process for writing excess data. Any slave process running on the same node may read from the one or more disk segments. 
     Some queries include iterative operations that reference results stored for prior iterations, while the final output of the query references results from multiple iterations. Results from all iterations may be stored in a single temporary table, with data indicating iteration values associated with each respective iteration. When data from a particular iteration is requested, the temporary table is scanned and a predicate is applied to find rows with the associated iteration value. However, this approach results in slower processing speeds since all the data from previous iterations are scanned, even ones that are not required for the operation. 
     The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       In the drawings: 
         FIG. 1  is a block diagram illustrating a multi-node database system; 
         FIG. 2  is a block diagram illustrating memory portions for storing temporary tables; 
         FIG. 3  is a block diagram illustrating a query that includes an iterative operation; 
         FIG. 4  is a block diagram illustrating a computer system that may be used to implement the techniques described herein. 
     
    
    
     DETAILED DESCRIPTION 
     In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, 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 avoid unnecessarily obscuring the present invention. 
     General Overview 
     Techniques are presented herein for storing iterations of an iterative query operation with the memory segments and disk segments in the nodes used for writing to cursor duration temporary tables 
     According to an embodiment, a portion of memory in each node of a clustered database system is allocated for storing in-memory cursor duration temporary tables. Each portion of memory may be divided into one or more memory segments. When data for an iteration is written to a memory segment, an iteration value for the iteration is associated with the memory segment. 
     According to an embodiment, each node has access to a disk, where a portion of the disk is used for storing in-memory cursor duration temporary tables. Each disk portion may be divided into one or more disk segments. If data for an iteration does not fit in a memory segment, the excess data may be written to a disk segment. If data for an iteration is stored in a disk segment, the iteration value for the iteration is associated with the disk segment. 
     When an iteration is executed by the database system, it may require data from one or more previous iterations. In an embodiment, prior to reading data from a memory segment, iteration values associated with the memory segment are checked to determine whether the memory segment contains data for the one or more previous iterations. If the memory segment does not contain relevant data, then the database system does not have to read from that memory segment. If any disk segments were used to store data, the iteration values associated with the disk segments are checked to determine whether any disk segments contain data for the one or more previous iterations. If a disk segment does not contain relevant data, then the database system does not have to read from the disk segment. 
     In Memory Cursor Duration Temp Tables 
     Various database languages, such as SQL, support special-purpose constructs referred to herein as “cursors.” During compilation of a query statement, the database server may perform a significant amount of preliminary work for the statement, such as parsing, semantic analysis, and query plan generation. A cursor stores much of the preliminary work. One set of information stored in a cursor includes the execution plan for performing the operations specified by the SQL statement. 
     An execution plan defines operations to be performed to execute a query and an order for performing the operations, known as plan operations. When a database instance receives a query, a query coordinator formulates a query execution plan for executing the query. The execution plan may specify that one or more plan operations are to be processed in parallel by one or more slave processes. 
     A plan operation may generate output that is stored in a temporary table for use during execution of another plan operation. If a query execution plan requires the use of temporary tables, one or more temporary tables are created and plan operations are written to reference the temporary tables. 
     In-memory cursor duration temporary tables refer to temporary tables that are stored primarily in local memory with excess data written to temporary disk segments. In a clustered database system, a portion of local RAM memory from each node in the cluster may be used to store in-memory temporary tables. The in-memory temporary may be divided into portions and each portion is stored in local memory of a node in the cluster. 
     System Overview 
       FIG. 1  depicts a multi-node database system on which an embodiment may be implemented. In the embodiment illustrated in  FIG. 1 , system  100  comprises three nodes,  102 ,  112 , and  122 . Although three nodes are shown in the present illustration, in other embodiments, system  100  may comprise more or fewer nodes. 
     Nodes  102 ,  112 , and  122  have access to the same database  160 . For the purpose of illustration, database  160  is shown as stored on a single shared disk  150 , but in alternative embodiments may be spread across multiple disks to which each of nodes  102 ,  112 , and  122  have access. 
     Nodes  102 ,  112 , and  122  respectively have one or more processors  108 ,  118 , and  128 , and local RAM memory  104 ,  114 , and  124 . In addition, nodes  102 ,  112 , and  122  are respectively executing database server instances  106 ,  116 , and  126 . While in the illustrated embodiment each node is executing a single database server instance, in alternative embodiments, a single node may execute more than one database server instance. 
     A portion of the local memory for each node may be used to store in-memory CDT data.  FIG. 2  illustrates the CDT memory portions in local memory of nodes in the database system. Local memory  104 ,  114 , and  124  comprise memory portion  204 ,  214 , and  224 , respectively. In an embodiment, memory portions  204 ,  214 , and  224  are allocated on start-up of the respective nodes  102 ,  112 , and  122  for storing in-memory CDTs. While in the illustrated embodiment each local memory comprises a single memory portion, in alternative embodiments, a node may have more or fewer memory portions. 
     Memory portions  204 ,  214 , and  224  may be directly accessed by processes running on the respective nodes. For example, memory portion  204  may be used by a process running on processor  108 . Similarly, memory portion  214  may be used by a process running on processor  118 . 
     In an embodiment, memory portion  204 ,  214 , and  224  are further divided into a plurality of memory segments. Each memory segment may be assigned to a process running on the node the memory portion belongs to. Each node may have a different number of memory segments and the memory segments may be of different sizes. In the present example, memory portion  204  comprises memory segments  204   a ,  204   b , and  204   c ; memory portion  214  comprises memory segments  214   a ,  214   b , and  214   c ; and memory portion  224  comprises memory segments  224   a ,  224   b , and  224   c.    
     In an embodiment, one or more portions of shared disk  150  are also used to store in-memory CDT data. The portions may be allocated when the database system starts, or may be allocated on an as-needed basis during query processing. 
     The one or more disk portions may be further divided into a plurality of disk segments. In an embodiment, a disk segment is allocated and assigned to a process writing in-memory CDT data when the CDT data requires more space than an assigned memory segment can hold. In another embodiment, each process writing in-memory CDT data is assigned a disk segment at the start of writing in-memory CDT data, regardless of the size of the CDT data. 
     Iterative Operations 
     A query may include one or more iterative database query operations. As used herein, an iterative operation refers to a query operation that is executed a number of times, such as a recursive operation. Certain computational tasks are performed using recursive operations, such as frequent item set determination and graph traversal. 
       FIG. 3  illustrates an example query that includes an iterative operation. For the purpose of illustration, assume table T represents the edges of a directed graph, and includes columns “fid,” “tid,” and “cost.” The “fid” column of a row indicates the starting point of an edge in the graph, the “tid” column indicates the end point of the edge, and the “cost” column indicates a distance or cost for traversing the edge. A database instance may receive query  300 , which traverses the graph represented by table T and outputs the cost of paths between nodes in the graph. 
     In the illustrated example, query  300  includes a recursive WITH clause “rw.” As used herein, a WITH clause is a database statement that provides an alias for a sub-query comprising one or more database operations. For example, if a query includes a particular sub-query multiple times, a user may define a WITH clause that includes the sub-query. The query may be written to reference the WITH clause rather than repeat the contents of the sub-query multiple times. In an embodiment, an execution plan for a query that includes a WITH clause may define and create a temporary table for the WITH clause. Plan operations that include the WITH clause may refer to the temporary table. 
     A recursive WITH clause is a WITH clause that references itself. In an embodiment, an execution plan for a query that includes a recursive WITH clause may define and create a temporary table for the recursive WITH clause. Each iteration of the recursive WITH clause uses the same temporary table to load and store data. 
     Based on the components of query  200 , the query coordinator generates an execution plan for executing the query. In an embodiment, the execution plan for a query that includes an iterative operation comprises at least three stages: an initialization stage, an iterative stage, and a finalization stage. 
     The initialization stage executes a single time. The initialization stage may include loading data to be used during execution of subsequent stages. In the present example, the initialization stage for query  200 , indicated by section  310 , includes scanning table T, selecting rows where the “fid” column equals  1 , and storing the results in a temporary table. 
     The iterative stage includes one or more iterative operations. The iterative stage may end after a particular number of iterations or when a particular exit condition is reached. In an embodiment, the execution plan indicates that the iterative operations repeat, but may not indicate the number of iterations. The number of times an iterative operation iterates may not be determined until execution of the iterative stage completes. 
     In the present example, the iterative stage, indicated by section  320 , includes executing the recursive WITH clause “rw” and storing the results for each iteration in the temporary table. At the end of an iteration, any exit conditions are checked to determine whether to execute another iteration or to proceed to the finalization stage. In the present example, clause “rw” repeats while T.fid equals rw.TID or while the variable “count” is less than 10. 
     In an embodiment, the initialization stage and each iteration of the iterative stage is associated with an iteration value. The iteration value may be a number, string, or some other value that indicates a current iteration. For example, the initialization stage may be considered the initial iteration and is associated with an iteration value of 0. The first iteration of the iteration stage is then associated with an iteration value of 1 and the second iteration of the iteration stage associated with an iteration value of 2, such that the N th  iteration of the iteration stage is associated with iteration value of N. 
     An iteration may require data that was generated and stored for one or more prior iterations. For example, iteration N may require data from the last iteration N−1, some other prior iteration K, or a set of iterations, such as iterations L through N−1. In an embodiment, row of the temporary table are associated with a respective iteration value. Storing data in the temporary table may include storing the iteration value associated with an iteration. Techniques for associating data in a temporary table with one or more iteration values is discussed in further detail below. 
     As illustrated in  FIG. 3 , recursive WITH clause “rw” includes an iterative operation that calls another iteration of clause “rw:” 
     SELECT rw.fid, T.tid, rw.cost+T.cost, rw.count+1 
     FROM T, rw 
     Thus, each iteration of “rw” requires data (rw.fid, rw.cost, and rw.count) generated by the previous iteration of “rw.” In other words, for an iteration N of clause “rw,” the iteration requires data stored for iteration N−1. Rows generated by an iteration of “rw” may be stored with an iteration value that indicates its iteration number. 
     The finalization stage may include additional query operations on data stored in the temporary table and outputting a set of one or more results. In the present example, the finalization stage includes grouping all rows of the temporary table by the “fid” and “tid” columns, aggregating the “count” and “cost” columns for each group, and outputting the results. 
     Although the present example is described using recursive WITH, the techniques described herein can be used with other recursive operations, such as frequent item sets and connect by, or by non-iterative operations that request results generated by other query operations. 
     Associating Data with Iteration Values 
     If a row is associated with an iteration value, then data stored in a temporary table for that row may be associated with the iteration value. As discussed in the In-Memory application, data for a temporary table is stored in one or more memory portions and/or one or more disk portions. In an embodiment, a memory portion and a disk portions may be further divided into one or more memory segments and one or more disk segments, respectively. For the purpose of illustrating a clear example, techniques are described with reference to segments, but may be used with portions, blocks, or any other level of granularity. 
     In an embodiment, each memory segment or disk segment is associated with one or more iteration values of the data stored in each respective memory portion or disk portion. If a segment stores data for a single iteration, then it is associated with a single iteration value. If a segment stores data for multiple iterations, then it is associated with multiple iteration values. For example, if a memory segment stores data from iteration 4 and iteration 5, then the memory segment is associated with the iteration values for iteration 4 and iteration 5. If a memory segment only stores data for iteration 2, then it is associated only with the iteration value for iteration 2. A segment may be associated with one or more iteration values, and an iteration value may be associated with one or more segments. The number of iterations associated with a segment may vary depending on the size and number of rows for an iteration and the size of the segment. 
     In an embodiment, the database system stores a data structure that indicates segment information for a temporary table. The data structure may include information about the number of segments, the size and location of each segment, and one or more iteration values associated with each portion. In an embodiment, the database system stores a data structure for memory segments and a separate data structure for disk segments. In other embodiments, the data structure indicates both disk and memory segments. 
     In an embodiment, after a slave process writes data to a segment, it indicates in the data structure a segment ID, an iteration value to associate with the segment, and the start and end location for the iteration value. For example, the data structure may indicate the starting block number and an ending block number within a segment for a set of data blocks. 
     Pruning Using Iteration Values 
     An iteration may require data stored in the temporary table from one or more previous iterations. Rather than reading the entire temporary table and filtering rows from the results, the temporary table may be pruned so that only the data for the relevant iteration(s) is read. Prior to reading a row from the temporary table, the database system determines if the iteration value associated with the row matches an iteration value associated with one or more requested iterations. 
     In an embodiment, each memory segment or disk segment is associated with one or more iteration values. Prior to reading data from a segment, the database system determines if at least one of the one or more iteration values of the segment is an iteration value associated with a requested iteration. In an embodiment, the data structure indicating segment information is used to determine which segments include data associated with the one or more requested iteration values. 
     In an embodiment, the slave processes each select a particular memory segment or disk segment to read. A slave process may select a segment to read based on the segment information stored in the data structure. In an embodiment, a slave process determines, based on one or more iteration value associated with a segment in the data structure, whether the segment includes data for a desired iteration. If the segment contains data for a desired iteration, the slave process reads from the segment. 
     In an embodiment, the data structure indicates the start and end location within a segment that stores data for an iteration. A slave process may select a segment and read only from the portion of the segment that stores data for a requested iteration. For example, if blocks  150  to  2000  of a segment store data for a requested iteration, then a slave process may generate a work granule that includes reading from block  150  to block  950 . The slave process may indicate the location it read to. Another slave process may generate a work granule that reads from block  951  to block  2000 . 
     In an embodiment, the database system also generates and stores a column in the temporary table indicating an iteration value for a row. After data is read from the temporary table, the rows may be filtered based on the iteration value column. If a row that is not associated with the requested iteration is read, then it will still be filtered out. In an embodiment, the iteration value stored in the column may be based on the iteration value stored in the data structure, but may use a different set of values or a different data type. For example, the iteration value stored in the column may be an integer from  0  to N, while the iteration value stored in the data structure may be a string from “itr_1” to “itr_(N+1).” 
     DBMS Overview 
     A DBMS manages one or more databases. A DBMS may comprise one or more database servers. A database comprises database data and a database dictionary that are stored on a persistent memory mechanism, such as a set of hard disks. Database data may be stored in one or more data containers. Each container contains records. The data within each record is organized into one or more fields. In relational DBMS&#39;s, the data containers are referred to as tables, the records are referred to as rows, and the fields are referred to as columns. In object-oriented databases, the data containers are referred to as object classes, the records are referred to as objects, and the fields are referred to as attributes. Other database architectures may use other terminology. 
     Users interact with a database server of a DBMS by submitting to the database server commands that cause the database server to perform operations on data stored in a database, as well as other kinds of operations. A database command may be in the form of a database statement that conforms to a database language. A database language for expressing the database commands is the Structured Query Language (SQL). There are many different versions of SQL, some versions are standard and some proprietary, and there are a variety of extensions. Data definition language commands are issued to a database server to create or configure database objects, such as tables, views, or complex data types. DDL commands are used to configure a database server for a particular hardware environment, to configure computer resource usage of the database server, as well as other operating aspects of the database server. 
     A multi-node database management system is made up of interconnected nodes that share access to the same database or databases. Typically, the nodes are database server hosts interconnected via a network and share access, in varying degrees, to shared storage, e.g. shared access to a set of disk drives and data blocks stored thereon. Each node in a multi-node database system hosts a database server. A server, such as a database server, is a combination of software and an allocation of computational resources, such as memory, a node, and processes on the node for executing the integrated software components on a processor, the combination of the software and computational resources being dedicated to performing a particular function on behalf of one or more clients. 
     Resources from multiple nodes in a multi-node database system can be allocated to running a particular database server&#39;s software. Each combination of the software and allocation of resources from a node is a server that is referred to as a “server instance” or “instance.” A database server may comprise multiple database instances, some or all of which are running on separate computers, including separate server blades. 
     The term process refers to a computer system process, which is described below in the HARDWARE OVERVIEW. Processes that comprise a database server run under the control of the database server (i.e. can be created or terminated by the database server) and perform various database server functions. Such processes are referred to herein as database server processes. Database server processors include listeners, garbage collectors, log writers, “server processes” for database sessions for executing database commands issued by database clients (including processes executing within shared sessions), and recovery processes. 
     Data Blocks 
     A data block is a unit of persistent storage and is used by a database server to store one or row more database rows, or portions of rows, including one or more columns of a row. When rows are read from persistent storage, a data block containing the row is copied into a data block buffer in RAM and/or main memory of a database server. A data block usually contains multiple rows, and data block metadata describing the contents of the data block. Metadata includes control and formatting information, such as offsets to sequences of bytes representing rows or other data structures, and a list of transactions affecting a row. 
     A data block is referred to as being atomic because, at least in part, a data block is the smallest unit of database data a database server may request from a persistent storage device. For example, when a database server seeks a row that is stored in a data block, the data block may only read the row from a persistent storage device by reading in the entire data block. 
     A data block is associated with a data block address that uniquely identifies the data block and the data block&#39;s storage location within a storage device. A database server may request from a storage device a data block by data block address, or even by primary block address ranges of data blocks. 
     Hardware Overview 
     According to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. The special-purpose computing devices may be hard-wired to perform the techniques, or may include digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the techniques, or may include one or more general purpose hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. Such special-purpose computing devices may also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to accomplish the techniques. The special-purpose computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices or any other device that incorporates hard-wired and/or program logic to implement the techniques. 
     For example,  FIG. 4  is a block diagram that illustrates a computer system  400  upon which an embodiment of the invention may be implemented. Computer system  400  includes a bus  402  or other communication mechanism for communicating information, and a hardware processor  404  coupled with bus  402  for processing information. Hardware processor  404  may be, for example, a general purpose microprocessor. 
     Computer system  400  also includes a main memory  406 , such as a random access memory (RAM) or other dynamic storage device, coupled to bus  402  for storing information and instructions to be executed by processor  404 . Main memory  406  also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor  404 . Such instructions, when stored in non-transitory storage media accessible to processor  404 , render computer system  400  into a special-purpose machine that is customized to perform the operations specified in the instructions. 
     Computer system  400  further includes a read only memory (ROM)  408  or other static storage device coupled to bus  402  for storing static information and instructions for processor  404 . A storage device  410 , such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to bus  402  for storing information and instructions. 
     Computer system  400  may be coupled via bus  402  to a display  412 , such as a cathode ray tube (CRT), for displaying information to a computer user. An input device  414 , including alphanumeric and other keys, is coupled to bus  402  for communicating information and command selections to processor  404 . Another type of user input device is cursor control  416 , such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor  404  and for controlling cursor movement on display  412 . This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. 
     Computer system  400  may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system  400  to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system  400  in response to processor  404  executing one or more sequences of one or more instructions contained in main memory  406 . Such instructions may be read into main memory  406  from another storage medium, such as storage device  410 . Execution of the sequences of instructions contained in main memory  406  causes processor  404  to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. 
     The term “storage media” as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical disks, magnetic disks, or solid-state drives, such as storage device  410 . Volatile media includes dynamic memory, such as main memory  406 . Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid-state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge. 
     Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus  402 . Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications. 
     Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor  404  for execution. For example, the instructions may initially be carried on a magnetic disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system  400  can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus  402 . Bus  402  carries the data to main memory  406 , from which processor  404  retrieves and executes the instructions. The instructions received by main memory  406  may optionally be stored on storage device  410  either before or after execution by processor  404 . 
     Computer system  400  also includes a communication interface  418  coupled to bus  402 . Communication interface  418  provides a two-way data communication coupling to a network link  420  that is connected to a local network  422 . For example, communication interface  418  may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface  418  may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface  418  sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information. 
     Network link  420  typically provides data communication through one or more networks to other data devices. For example, network link  420  may provide a connection through local network  422  to a host computer  424  or to data equipment operated by an Internet Service Provider (ISP)  426 . ISP  426  in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet”  428 . Local network  422  and Internet  428  both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link  420  and through communication interface  418 , which carry the digital data to and from computer system  400 , are example forms of transmission media. 
     Computer system  400  can send messages and receive data, including program code, through the network(s), network link  420  and communication interface  418 . In the Internet example, a server  430  might transmit a requested code for an application program through Internet  428 , ISP  426 , local network  422  and communication interface  418 . 
     The received code may be executed by processor  404  as it is received, and/or stored in storage device  410 , or other non-volatile storage for later execution. 
     In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what is intended by the applicants to be the scope of the invention, is the literal and equivalent scope of the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction.