Context management system for modular software architecture

[0002] In a large scale computer system, such as a database management system (DBMS), it is important to be able to service a number of different users concurrently. Without such a capability, the system would be little more than a standalone computer. To implement multi-user support, several different processing models have been utilized. One model that has been used is the multi-processing model. In multi-processing, each time a new user requests access to the system, a separate process is started. This process is in essence a separate execution of the software. Once started, the process services all of the requests from the user that spawned it. Under the multi-processing model, each process has its own separate memory space for use in storing and processing data.

[0003] Multi-processing is effective for supporting multiple users concurrently; however, it has severe scalability limitations. This is due mainly to two factors. First, spawning and maintaining a process involves a significant amount of overhead. Because of the high cost, only a small number of processes can be maintained at any one time. Second, the same set of data, used by multiple processes, may be stored redundantly; once in each process' memory space. This redundancy can waste a significant amount of system resources.

[0004] To overcome some of the limitations of multi-processing, the multi-thread model was developed. According to the multi-thread model, there is only one execution of the software. That is, only one process is spawned. From this one process, multiple threads can be spawned to perform the work necessary to service user requests.

[0005] Multi-threading has several advantages over multi-processing. First, because only one process is spawned, overhead is kept to a minimum. It is true that each thread carries with it some overhead cost, but this cost is negligible when compared with the cost of maintaining an entire process. Because multi-threading significantly reduces system overhead, many more users can be supported. Another advantage of multi-threading is that it minimizes the redundant storage of data. Because all of the threads are part of the same process, all of the threads can share the same memory space, and other system resources associated with that process.

[0006] A typical method of constructing an executable computer program to support concurrent users includes compiling a plurality of source code files into machine-code object files. These object files are then linked together at build time to yield a tightly-coupled monolithic executable image. For complex applications, the executable can be quite large. Although monolithic executables operate efficiently, they have a number of drawbacks, including difficulty in programming, constructing, testing, and modifying the software.

[0007] In accordance with preferred embodiments of the invention, a context management system manages both thread-local data and free-thread data in a flexible modular architecture. Preferably, thread data is segmented into an ordinal workspace structure. In a free thread architecture, each module can have its own private and public segments. The context management system allows many threadable, session contexts to share a lesser number of real operating system threads, maintained as a thread pool within the server process.

[0008] In accordance with a preferred embodiment of the invention, a multi-session computing system is programmed with a system for managing session context. First, a computer program is concurrently executable by a plurality of sessions. In particular, the computer program comprises a plurality of linked modules, each module programmed with a subset of the computer program. The modules are linked in a preassigned order to yield the computer program. The sessions are initiated by a plurality of clients, a module provides the interface between the computer program and a client.

[0009] Each session can include a plurality of transactions. A thread manager is included to assign computing threads to sessions. In a particular embodiment, a free-thread pool is managed by the thread manager.

[0010] A plurality of data segments are generated and accessible to the computer program for storing session data. A data segment can include a private subset of data and a public subset of data.

[0011] A database structure relates each session with at least one data segment to provide each session access to the stored session data. The database structure preferably includes an array of pointers to the data segments to bind a module with a data segment. A database manager module associates the database structure with the session data, the modules and the data segments. That association is provided by a computed index into the database structure.

[0012] The above and other features of the invention, including various novel details of construction and combination of parts, will now be more particularly described with reference to the accompanying drawings and pointed out in the claims. It will be understood that the particular system for dynamically constructing an executable computer program embodying the invention is shown by way of illustration only and not as a limitation of the invention. The principles and features of this invention may be embodied in varied and numerous embodiments without departing from the scope of the invention.

[0013] FIG. 1 is a schematic block diagram of a computing system in accordance with a preferred embodiment of the invention.

[0014] FIG. 2 is a schematic block diagram of module registration and resolution in accordance with a preferred embodiment of the invention.

[0015] FIG. 3 is a flowchart of a preferred method of preparing an executable software program in accordance with the invention.

[0016] FIG. 4 is a schematic block diagram of a typical module in accordance with a preferred embodiment of the invention.

[0017] FIG. 5 is a process flow diagram for typical module operations in accordance with a preferred embodiment of the invention.

[0018] FIG. 6 is a schematic block diagram of a preferred context management system in accordance with the invention.

[0019] FIG. 7 is a schematic block diagram of a workspace manager module.

[0020] FIG. 8 is a process flow diagram for typical workspace operations within the host server computer 1 of FIG. 1.

[0021] FIG. 1 is a schematic block diagram of a computing system in accordance with a preferred embodiment of the invention. Illustrated is a host computer system 1 having a plurality of Central Processing Units (CPU) 2₁, 2₂, . . . , 2p for executing program instructions from a software architecture 3. The software architecture 3 includes a server operating system environment 5 and an application environment 7. In the operating system environment, an operating system kernel 10 comprises a system initializer 12 and a module manager 14. The system initializer 12 and the module manager 14 are employed to construct an application software program 20 in the application environment 7 from a plurality of modules 24. In a particular preferred embodiment of the invention, the application software program 20 is a server-based on-line analytical processing (OLAP) program which communicates with a paging manager 16 to access data stored in databases 52 on a disk 50.

[0022] The user sessions and system management processes preferably include processing threads managed by the thread manager 18 in a multi-threaded OLAP engine. That is, user sessions can accomplish tasks by asynchronously executing processing threads. In particular, the thread manager 18 preferably manages a free thread pool having a plurality of pre-instantiated computing threads.

[0023] Embodiments of the invention preferably take the form of computer executable instructions embedded in a computer-readable format on a CD-ROM, floppy disk or hard disk, or another computer-readable distribution medium. These instructions are executed by one or more processors 2₁, 2₂, . . . , 2p to implement the system software and OLAP software. Particular embodiments of the invention are commercially available as Express Server, Versions 6.0, 6.0.1, 6.0.1.2, and 6.1, from Oracle Corporation.

[0024] The system initializer 12 is automatically executed once the kernel 10 is established on the host computer 1. The initializer 12 responds to configuration information from a configuration file 30 which has been created by a system administrator. The configuration file 30 lists all relevant modules 24 making up the application software program 20 and where the module files are located on disk. The system initializer 12 reads the configuration information and loads the modules that make up the application software program 20 into memory.

[0025] Once the modules 24 are loaded, the module manager 14 is executed to dynamically construct the modules into an operational set of code (i.e., the application software 20) by performing a number of different functions. The module manager 14 creates and maintains a module database 40 and an interface database 45. The module database 40 is essentially a list, derived from the configuration file 30, of all the modules 24 making up the application software program 20. The module manager 14 calls each of the modules to register each of the interfaces that the module supports into an interface database 45. Information that is registered includes the name of the interface and the pointer to the interface.

[0026] As the term is used herein, a module is a subset of object files and functionality that are linked together. Each module has a bootstrapping entry point or an exportable method called modMain. A module is preferably dynamically loadable and can be included in a function library with an entry point.

[0027] Each module also provides at least one interface for services. An interface provides a binary contact point between a supplier method and a consumer method. These complete interfaces are registered with the central interface database 45. Each module and interface is identified using a burned-in, universally unique identifiers (UUID). Typically, each module references one or more interfaces registered by other modules via the interface database 45. The modules can also provide a mechanism to dynamically cope with missing interfaces in the code image. Modules support standard callback interfaces for all management functions.

[0028] In addition, a module can support thread-local data (i.e., workspace) operations and can be optimized for multi-threaded operations. Modules also store and present version validation information. The modules also provide for dynamic integrity checks of process and thread run-time data integrity.

[0029] A module also has an organized code structure, clear functionality boundaries and highly-encapsulated data organization. Modules support global (process-oriented) constructors and destructors for appropriate initialization and termination processing. Similarly, the modules can support thread data-oriented constructors and destructors for appropriate initialization and termination processing. The modules also provide ordinality for coordinating global, thread local and error recovery processing across modules.

[0030] FIG. 2 is a schematic blockldiagram of module registration and resolution in accordance with a preferred embodiment of the invention. As illustrated, there is a startup module 22 and a plurality of worker modules 24. Each module 22, 24 can define function method interfaces 27 or reference method interfaces 29 defined by other modules. The module database 40 includes a list of module entries 42 and the interface database 45 includes a list of pointers 47 to registered interfaces.

[0031] As illustrated, the startup module 22 defines two interfaces, Inf_1 and Inf_2. The identifiers for these interfaces along with the pointers to the function entry points for these interfaces are stored as entries 47 in the interface database 45.

[0032] A first worker module (MOD_A) 24A defines three interfaces, Inf_3, Inf_4 and Inf_5. Pointers to these interfaces are stored by the module manager as entries 47 in the interface database 45.

[0033] A second worker module (MOD_B) 24B defines one interface, Inf_7, and references two interfaces, Inf_5 and Inf_3. A pointer for the defined interface is stored in the interface database 37. Similarly, a third worker module (MOD_C) 24C defines a single interface, Inf_6, and references interfaces Inf_7 and Inf_3.

[0034] Note that the module database 40 specifies in what order the modules are loaded. In particular, the modules are loaded in an order such that interface references are always to an interface which has already been enabled for execution at a later, precise state of software initialization.

[0035] After the registration process, the module manager 14 recognizes all interfaces that are supported by the application software 20 and how those interfaces can be located and invoked. Thereafter, the module manager 14 resolves all of the interfaces for all the modules. In this process, the module manager provides to each module, for each interface that the module needs, a pointer to the needed interface. The interface references 29 are thereby dereferenced using the pointers stored in the interface database 45 for the respective interfaces. By so doing, the module manager 14 is tightly binding all the modules together by way of the pointers into a single set of executable code. The software is thus dynamically constructed.

[0036] FIG. 3 is a flowchart of a preferred method of preparing an executable software program in accordance with the invention. At step 105, the kernel 10 is started by the host server computer operating system. At step 110, the kernel 10 executes the system initializer 12, which determines the software configuration of the executable image of a target software application from the configuration file 30. At step 115, the system initializer 12 loads the required software modules into memory. At step 120, the module manager constructs an executable image for the target software. At step 125, the system constructs the global system to make the modules runnable. In particular, the module manager 14 calls each module to execute a global construction method. At step 130, the target software is initialized. Finally, at step 135 the kernel 10 resolves every external interface (Remote Procedure Call (RPC), Express Communications Architecture (XCA), Remote Oracle, etc.) to open the client communities for access to the target software.

[0037] FIG. 4 is a schematic block diagram of typical module in accordance with a preferred embodiment of the invention. Each module 24 preferably includes a plurality of standard entry points 25, modMain 50, modInitMod 51, modResolve 52, modUnresolve 53, modCreateWs 54, modDestroyWs 55, modQueryProcess 56, modQueryWorkspace 57, modUnregister 58, and modDestroyMod 59. The modMain 50 function verifies the module and registers the interfaces. The modInitMod function 51 is a global constructor for the module. The modResolve function 52 is invoked to resolve module interfaces. The modUnresolve function 53 is called to unresolve a single interface. The modCreateWs function 54 is a constructor for thread-local (workspace) data. The modDestroyWs function 55 is a destructor of the thread-local (workspace) data. The modQueryProcess function 56 is invoked to query module integrity. The modQueryWorkspace function 57 is called to query workspace integrity. The modUnregister function 58 is invoked to unregister all defined interfaces of the module. The modDestroyMod function 59 is a global destructor.

[0038] In addition to the standard entry point 25, a module 24 can include a plurality of service methods 27a, . . . ,27neach having a respective interface. Further details and advantages of dynamically constructing an executable computer program from modules are described in U.S. patent Ser. No. 08/866,744 entitled “System For Dynamically Constructing an Executable Computer Program” and filed on May 30, 1997 by R. Scott Gongwer et al., the teachings of which are incorporated herein by reference in their entirety.

[0039] FIG. 5 is a process flow diagram for typical module operations in accordance with a preferred embodiment of the invention. First, at step 310 the operating system calls the dynamic library entry point for the module. At step 320, the module manager now calls modMain, which causes the module to validate itself at step 322 using the module version data and to register all the interfaces it provides at step 324. In particular, all modules register a common module interface and possibly a common thread local data interface.

[0040] The module manager next calls the global constructor, modInitMod, at step 330. In response, at step 332 the module resolves external interfaces provided by other modules. The module then starts thread-local data management for the module at step 334. Each module now calls its global constructor (modInitMod) to initialize process-level data at step 336 and a workspace constructor (modCreateWs) to initialize thread-level data at step 338.

[0041] At the end of the last transaction for a session (step 340), each module calls its workspace destructor (modDestroyWs) to deinitialize thread-level data at step 342. Each module then calls its global destructor (modDestroyMod) to deinitialize process-level data at step 344. Each module then stops thread-local data management for the module at step 346. Each module then unregisters all the interfaces it provides by calling modunregister at step 348 and, finally, unloads itself from the process code image at step 350.

[0042] By employing dynamic software construction, service interfaces can be separated from fixed modules. Interfaces are thus portable and can be migrated from one module to another. In other words, module boundaries can be adjusted or redefined to include or exclude a particular service. In addition, multiple generations of a service can operate in a single executable application program.

[0043] Also, any session creation, transaction, or destruction can execute using any thread within the process. To be effective, each thread must have context information regarding the session data to access to accomplish a task. In a free-thread environment it is particularly difficult to maintain context.

[0044] In a preferred embodiment of the invention, a workspace structure is utilized to control session context. As briefly described above, the workspace structure is controlled by modules. The modules can provide a template for initializing the workspace, a constructor for private workspaces, a destructor for private workspaces, and a routine to query private workspaces.

[0045] FIG. 6 is a schematic block diagram of a preferred context management system in accordance with the invention. Data is stored in a workspace structure 70 divided into workspace segments 72₁-1, . . . , 72₁-L; 72₂-1, . . . , 72₂-M; 72₃-1, . . . , 72₃-N. Each workspace-enabled module 24₁, 24₂, 24₃can have a plurality of workspace segments 72, each with a private section 74 and public section 76. Particular details and advantages of the workspace structure 70 are described in U.S. patent application Ser. No. 08/866,619, entitled “Computing System For Implementing a Shared Cache” and filed on May 30, 1997 by James E. Carey, the teachings of which are incorporated herein by reference in their entirety.

[0046] The workspace structure 70 includes page buffers 74, 76 each having an associated page control block (PCB). Each page buffer 74, 76 holds a page of data read from storage 60. In accordance with a preferred embodiment of the invention, the page buffers 74,76 each store data in blocks of 4K bytes, defined as a page. It should be understood that the page size can be chosen to be either less than or greater than 4K bytes. The page control blocks include data fields used to control and access associated page buffers 74, 76. The workspace structure 70 is shared by the user sessions to store both public and private data.

[0047] It is important to note that there is no physical division between public and private data pages. That is, a particular page buffer 74, 76 simply stores a page of data, which can be either public or private data. It is up to the OLAP engine to logically separate public and private data pages.

[0048] A user session uses the above architecture by executing paging manager code. For data to be processed by a session, the data must be retrieved from mass storage 60 and stored in a page buffer 76 in the workspace segment 72. Once the data is retrieved, the page buffer 76 can be publicly accessed by any user session. If the data is to be modified, such as for a what-if analysis, then the data is copied to a private page buffer 74, leaving the original data in the public page buffer 76.

[0049] The kernel 10 communicates with a workspace manager module 24₀and a plurality of workspace-enabled modules 24₁, 24₂, 24₃, . . . Each workspace segment 72 for a module persistently stores transaction data, but is only associated with a thread during the life of a transaction. A particular thread can access data stored in a group of workspace segments 72, one per workspace-enabled module in the context.

[0050] A prototypical workspace structure in ANSI C for a module is as follows:

[0051] Each workspace-enabled module has a common workspace interface, a workspace management interface, and a workspace constructor/destructor interface. Each interface includes a UUID and a structure definition that includes well-typed methods. The system maintains an instance of the common workspace interface for each workspace-enabled module. A common workspace callback interface is as follows:

[0052] FIG. 7 is a schematic block diagram of a workspace manager module. The workspace manager 24₀includes a modMain method 50₀as described above and a plurality of manager methods 27₀. The manager methods 27₀includes a wmAddMod method 81 to add a calling module to the workspace database 65 and a wmDeleteMod method 84 to remove a calling module from the workspace database 65. A wmFindWsa method 82 allocates the workspace array 67 in the workspace database 65 and a wmFreeWsa 83 deallocates the workspace array 67 for the current transaction. The constructAllWs method 88 and destructAllWs method 89 builds and shuts down the whole segmented workspace context for a session, respectively. During system startup, shutdown, and exception handling, the wmCountWs 85, wmDumpWs 86, and wmGetWsHandles 87 methods are used to navigate the deinitialize workspace segments.

[0053] A workspace management interface for all classes of modules is as follows:

[0054] A workspace construction/destruction interface for all classes of modules is as follows:

[0055] Returning to FIG. 6, a user session is initiated by a client access of the workspace manager 24₀. As illustrated, certain modules 24 function as listeners for specific interface protocols; e.g., Simplified New Application Programming Interface (SNAPI), Hypertext Transfer Protocol (HTTP), XCA, etc. By calling the kernel 10, the modules 24 can access data from the database using the paging manager 16 and store retrieved data in the appropriate workspace segment 72. In particular, clients 8A, 8B, 8C interact with the server 1 using a free-pool, threaded communications mechanism, such as Distributed Computing Environment/Remote Procedure Call (DCE/RPC), or Oracle Remote Operations. As illustrated there is a DCE/RPC listener 28₁for a SNAPI client 8A, an HTTP listener 28₂for a worldwide web client 8B, and an XCA socket listener 28₃for an XCA client 8C. These software items 28 listen for client transactions and hand over a client identifier to any thread in their thread-pool. The client identifier is immediately presented to the wmFindWsa method 82 in the workspace manager 24₀, cast as a workspace session handle. An array of workspace segment pointers is returned and carried on the stack for all subsequent methods, allowing proper mapping of workspace data, for any method of any module in the server.

[0056] The workspace manager controls a workspace database 65 which includes an array of pointers 67 to workspace segments 72 in each context. The workspace array is preferably a double-linked list, accessible by session and segment values. During a session transaction, the client passes a context handle to the workspace manager. The context handle is a ticket which facilitates interaction between a client 8 and the workspace manager 24₀. The context handle is passed with every function call and is put on the stack.

[0057] In response, the workspace manager 24₀retrieves the pointers from the workspace database 65 and returns them to the thread in a workspace array structure (WSADECL). To perform a query, or otherwise access data, the workspace array structure is passed into the modules. Based on the pointers, each module can determine which of its workspace segments to access.

[0058] As execution flows from module to module, each module's workspace index value is then used to dynamically dereference the local workspace segment pointer from the workspace database 65. The pointers 67 are placed such that their array location and their respective module workspace index value are synchronized. Furthermore, the pointer array 67 is presumed to be dense with no missing pointers during transaction processing, but can have missing elements during construction or destruction. In these two cases, the module workspace indexes determine the ordinality of construction and destruction, allowing for orderly construction counting up the index values and orderly destruction counting down the index values. Thus, modules can call methods of any other module with a lower index value during construction or destruction.

[0059] The workspace segment array 67 is guaranteed to be valid for the duration of the transaction, and returned to the workspace manager 24₀by the wmFreeWsa method 83 at the end of the transaction. The thread is then returned to the thread-pool by the communication mechanism.

[0060] FIG. 8 is a process flow diagram for typical workspace operations within the host server computer 1 of FIG. 1. First, after being loaded into memory by the server 1 as described above, each module registers its common workspace interface at step 410.

[0061] At step 420, the module calls the workspace manager's wmAddMod method 81 to register itself with the workspace manager as a workspace-enabled module. This enters the module in the workspace database 65 at step 422. Registration hands each module a unique index value representing the workspace segment associated with that module at step 424.

[0062] The server system, comprised of multiple, workspace-enabled modules, listens for client applications to begin sessions. At the beginning of each session, at step 430, the workspace manger's constructAllWs method 88 is called to build the whole, segmented workspace context, to support transactions on behalf of the client. The constructAllWs method 88 calls each module's modCreateWs method 54 (FIG. 4) at step 432 to construct session-level data. Construction can be polymorphic, based on values in the public portion of each workspace structure. For example, any module may tailor its workspace segment construction based on the data in the clienttype common workspace element. The result will be different behavior for the module's interface methods for each type of client using the software. Construction can be implemented via templates or code algorithms.

[0063] Each session typically iteratively starts and ends a plurality of transactions. Each transaction starts by calling the workspace manager's wmFindWsa method 82 at step 440. At step 442, this method builds an array of workspace segment pointers, ordered within the array by module index. Each transaction ends by calling the workspace manager's wmFreeWsa method 83 at step 450. At step 452, this method deallocates the workspace segment array.

[0064] The server system, again comprised of multiple, workspace-enabled modules, listens for client applications to end sessions. At the end of each session, at step 460, the workspace manager's destructAllWs method 89 is called to shut down the whole, segmented workspace context. Destruction can be implemented via code algorithms. At step 462, the destructAllWs method 89 calls each module's modDestroyWs method 55 (FIG. 4) at the end of the session to destruct session-level data.

[0065] At step 470, each module can stop workspace management for its segment by calling the workspace manager's wmDeleteMod method 84. Each module unregisters the common workspace interface at step 472 and can then unload itself from the process code image.

[0066] Returning briefly to FIG. 4, each module provides an integrity verification function for its workspace segment called modQueryWorkspace 57. When processing errors are detected by the server, each module's modQueryWorkspace method 57 is called to check the validity of the session data. If any, modQueryWorkspace method 57 returns a failure code, the session is deconstructed and the client is disconnected.

[0067] Throughout the code of each module, references to workspace data elements are wrapped in macros that make coding easy and compile in the proper workspace pointer dereferencing logic. For example, in program foo, in module1, that calls function foo2 in module 2 to process data and then return value foovalue, the prototypical code can be:

[0068] This code would then resolve to:

[0069] The above macro model supports both bound threads and free-thread embodiments of the invention. Using bound threads, the workspace manager can be compiled out of the system.

[0070] While the invention has been particularly shown and described with reference to preferred embodiments thereof, it will be understood to those skilled in the art that various changes in form and detail can be made without departing from the spirit and scope of the invention as defined by the appended claims. For example, although the invention has been described with reference to particular hardware and software embodiments, it will be understood that various aspects of the invention can be embodied in either hardware, software or firmware.

[0071] These and all other equivalents are intended to be encompassed by the following claims.