JP7148570B2 - System and method for parallel startup of application servers - Google Patents

Description

COPYRIGHT NOTICE A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent document or the patent disclosure as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights.

FIELD OF THE INVENTION The present invention relates generally to computer systems, and more particularly to transaction processing environments.

background
A conventional mechanism for booting Tuxedo applications (ie, tmboot) typically boots Tuxedo application servers one by one in a predetermined order. For large/complex applications, undesirably long start-up times.

SUMMARY A system and method are provided for parallel launching application servers. In an exemplary method, each server and server group entry can be associated with a dependency attribute. The method can create a dependency map based on the dependency attributes. This method, when invoked, can spawn each server in parallel that has no dependencies. Based on the dependency map, the remaining servers and server groups can be started.

Conventionally, Tuxedo allows application servers to be started according to sequence parameters. In this case, when the administrator calls tmboot (to start the server to use the application), the application server is started according to the assigned sequence number/parameters. This can slow down the server startup sequence.

The systems and methods described in this disclosure add the DEPENDSON attribute to groups and servers. Application servers are started in the order specified by the DEPENDSON parameter. This allows application servers to be started in parallel, making the start-up process faster and more efficient.

1 illustrates an example transaction processing environment, according to one embodiment; FIG. [0012] Figure 4 illustrates parallel launching of application servers, according to one embodiment. FIG. 4 is a flowchart illustrating an exemplary method for parallel launching application servers in a transaction processing environment; FIG.

DETAILED DESCRIPTION The present invention is illustrated by way of example and not by way of limitation in the accompanying drawings. In the figures of the accompanying drawings, like reference numerals indicate similar elements. It should be noted that in this disclosure, references to one embodiment, one embodiment, or several embodiments are not necessarily limited to the same embodiment, but mean at least one embodiment.

When describing specific implementations, it should be understood that these specific implementations are provided for illustrative purposes only. A person skilled in the relevant art will recognize that other elements and configurations can be used without departing from the scope and spirit of the invention.

The following description of the invention uses the Tuxedo® environment as an example of a transactional middleware machine environment. It will be apparent to those skilled in the art that other types of transactional middleware machine environments can be used without limitation.

In some cases, numerous specific details are given to provide a thorough description of the invention. However, it will be apparent to those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known features have not been described in detail so as not to obscure the invention. For example, the detailed description uses the XA distributed transaction environment as an illustration. It will be apparent to those skilled in the art that the present invention is applicable, without limitation, to other types of distributed transaction environments.

Common reference numbers are used in the drawings and detailed description to refer to similar elements. Therefore, when describing elements illustrated elsewhere, the reference numbers used in the figures do not necessarily appear in the detailed description corresponding to this figure.

This disclosure describes systems and methods for parallel launching application servers in a transaction processing environment.

Transaction Middleware Environment The transaction middleware system is designed to provide a complete Java EE application server complex that includes a massively parallel processing in-memory grid that can be provisioned quickly and scaled on demand. , high-performance hardware such as 64-bit processor technology, high-performance large memory, redundant InfiniBand and Ethernet networks, and an application server or middleware environment such as the WebLogic suite including. The system of the present invention can be deployed as full-rack, half-rack or quarter-rack or other configurations forming application server grids, storage area networks and InfiniBand (IB) networks. Middleware machine software includes application servers, middleware and other functions such as WebLogic Server, JRockit or Hotspot JVM, Oracle® Linux® or Solaris, and Oracle® VM. can provide. The system of the present invention comprises I
It may include multiple compute nodes, IB switch gateways, and storage nodes or units that communicate with each other over a B network. When implemented as a rack configuration, unused portions of the rack may be left empty or filled with padding.

For example, in a system such as "Sun Oracle Exalogic" or "Exalogic", the system of the present invention is an easy-to-deploy solution for hosting middleware or application server software such as the Oracle® middleware SW suite or WebLogic. is. As described in this disclosure, a transactional middleware system is a "grid" that includes one or more servers, storage units, an IB fabric for the storage network, and all other elements needed to host middleware applications. It is a grid in a box. For example, all types of middleware applications can provide high performance. The system provides improved performance through linear I/O scalability, is easy to use and manage, and provides mission-critical availability and reliability.

According to one embodiment of the present invention, a transaction middleware system, such as a Tuxedo system, utilizes high-speed machines with multiple processors, such as Exalogic middleware machines, and high-performance network connections, such as InfiniBand (IB) networks. can be done.

The Oracle Tuxedo system is a set of software modules that enable the building, execution and management of high-performance distributed business applications and is used as transaction middleware in many multi-tier application development tools. Tuxedo is a middleware platform that can be used in distributed computing environments to manage distributed transaction processing. Tuxedo is an effective platform for unlocking enterprise legacy applications and extending enterprise legacy applications to service-oriented architecture while providing unlimited scalability and standards-based interoperability.

Tuxedo also provides a service-oriented infrastructure for efficiently routing, distributing and managing requests, events, application queues between system processes, and application services. Tuxedo scales virtually without limit, improving business agility by efficiently managing peak transaction volumes, enabling IT organizations to quickly respond to changing business demands and throughput. . Oracle Tuxedo optimizes transactions across multiple databases and ensures data integrity across all participating resources, regardless of access protocol. The system ensures that all transaction commits and rollbacks are properly handled by tracking transaction participants and overseeing the extended commit protocol.

In addition, the Oracle Tuxedo system supports the XA standard, the X/Open ATMI API, the X/Open Distributed Transaction Processing: TX ( The Open Group's X/Open standards, including the Transaction Bounding Specification, and the X/Open Portability Guide (XPG) standards for language internationalization. A transaction application server may be referred to as an XA server when using the XA standard. For example, each Tuxedo application server belonging to a Tuxedo group can be configured to use the OPENINFO attribute. All XA servers within a Tuxedo group can use the OPENINFO attribute to form a connection with a resource manager (RM).

Sequential Startup of Tuxedo Application Servers Conventionally, Tuxedo allows application servers to be started according to sequence parameters. In this case, when the administrator calls tmboot (to start the server to use the application), the application server is started according to the assigned sequence number/parameters.

Application servers can be started in the order specified by a sequence parameter (SEQUENCE parameter) or in the order of server entries in a configuration file (eg, UBBCONFIG). If two or more servers have similar SEQUENCE parameters, tmboot will boot these servers in parallel and will not continue operation until all servers have completed initialization.

If a server fails to boot, tmboot writes diagnostics to the main event log and the failed server is the parent server (i.e. the server booted after the failed server is working fine). The operation can continue unless (for some reason it depends on a server that could not be started).

Thus, if a server that fails to start and/or initialize is a prerequisite for starting other servers in the boot process, or if the server cannot be verified, it is undesirable for the application server's boot process. Delays may occur.

Parallel Startup of Tuxedo Application Servers Based on Dependencies FIG. 1 is a diagram that illustrates a transaction processing environment 100 . More specifically, FIG. 1 illustrates a process for parallel launching Tuxedo application servers within transaction processing environment 100 .

According to one embodiment, within the transaction processing environment 100, an administrator 110 can launch one or more application servers 130, such as Tuxedo application servers, using a command such as tmboot and a boot map 115. . After an application server is started and initialized, it can communicate with one or more databases 140 and can be utilized by applications 120 .

According to one embodiment, the boot map 115 can include a boot plan for launching two or more application servers 130 in parallel, and can capture dependencies between servers and server groups.

According to one embodiment, an option can be added to tmboot to launch Tuxedo application servers in parallel. This option can be the "-p num" option added to tmboot to specify that the application servers should be started in parallel mode. A new keyword "DEPENDSON" can also be added to groups and servers in UBBCONFIG to specify the boot order of Tuxedo application servers when using the tmboot command.

According to one embodiment, a "-p num" option added to tmboot can specify that the application server should be started in parallel mode. "-p" means to start application servers in parallel. "num" means the number of servers that can be started at the same time. For example, tmboot with "-p 1" is the same as tmboot without the "-p" option. If num=0, the system can use the initial number, say 16.

According to one embodiment, the methods and systems described in this disclosure can add keyword DEPENDSON attributes to groups and servers. The application server uses the order specified by the DEPENDSON or SEQUENCE parameters or in the configuration file (
For example, they can be started in order of server entries in UBBCONFIG(5)). DEPENDSON
If the parameter and the SEQUENCE parameter are specified together, the DEPENDSON parameter takes precedence.

According to one embodiment, the method and system described in this disclosure provide tmboot with the option "-p
<number>" can be added. All application servers that do not have DEPENDSON relationships set in UBBCONFIG will start in parallel. In order to boot the servers in order according to their dependencies and to run in parallel, tmboot must wait until each server has booted.

According to one embodiment, when operating in SHM (shared memory) mode, tmboot starts all servers running in parallel and waits for responses from the started servers. These servers send responses over pipes to the tmboot process, which receives the responses and runs the next job.

According to one embodiment, when running in MP (multi-process) mode, tmboot and tlisten can create another thread that exchanges information with each other. This local thread can wait for messages to be sent from the remote machine. Notifies the main thread to continue if there are servers started remotely. A remote tlisten thread prepares to collect responses from the spawned server. When one server starts or fails, it notifies local threads via network messages.

FIG. 2 is a diagram illustrating parallel launching of application servers, according to one embodiment.

According to one embodiment, FIG. 2 includes several servers, e.g. (210), the dependencies of S24 (205) and the parallel activation map. The dependency and parallel activation map also includes several server groups including G1 (212), G2 (213), G3 (216) and G4 (218).

According to one embodiment, the dependency and parallel activation map 200 of FIG. 2 can be constructed based on the dependencies between servers and groups.

According to one embodiment, as shown in FIG. 2, there may be multiple server groups. That is, a server group may include G1, G2 and G3 (three).

G1 includes servers S11, S12 (DEPENDSON S11), S13 and S14. Using the notation (DEPENDSON), S1 initiated and initialized for normal functioning of S12
2.

G2 includes servers S21, S22 (DEPENDSON S21), S23 (DEPENDSON G1.S13, S24) and S24. Here, the notation (DEPENDSON) can be used to indicate that S22 depends on S21 being activated and initialized to function properly. Similarly, S32 depends on S13 and S24 (of G1) being activated and initialized to function properly.

G3 (DEPENDSON G1, G2) may include servers S31 and S32. Here, groups G1 and G2 must be fully activated and initialized for G3 to function properly.

G4 can include S41, S42 (DEPENDSON S41, G3), and S3. Here, the notation (DEPENDSON) can be used to denote S41 and G3 that have been activated and initialized for G4 to function normally.

According to one embodiment, the parallel startup map 200 of FIG. 2 may be constructed and the servers started 201 to parallelize S11, S13, S14, S21, S24, S41, S43. After activating S11, S12 can be activated. After activating S21, S22 can be activated. After activating S13, S24 can be activated, and then S23 can be activated. After starting G1 (S11, S12, S13, S14) and G2 (S21, S22, S23, S24), servers S31, S32 can be started in parallel. After activating G3 (S31, S32) and S41, S42 can be activated. After activating S42 and S43, G4 is activated and initialized.

According to one embodiment, after booting all servers, the tmboot task initiated by the administrator can be completed.

FIG. 3 is a flowchart illustrating an exemplary method for parallel launching application servers in a transaction processing environment. The method begins at step 310 . At step 310, the method may load multiple server entries and multiple group entries into memory. Each of the plurality of server entries is associated with one of the plurality of servers, and each of the plurality of group entries is associated with one of the plurality of server groups. At step 320, the method may create a dependency map between multiple servers and multiple group entries. At step 330, the method may continue to check for non-dependent servers among the plurality of servers. At step 340, the method may parallel start each server that has no dependencies among the plurality of servers. At step 350, the method may continue by initializing each server that has no dependencies among the plurality of servers. At step 360, the method may start the remaining unstarted servers according to the created dependency map.

Boot Process According to one embodiment, when tmboot is run, the exemplary process can load server and group entries from TUXCONFIG into memory. The process can then set dependencies between the server node and the group node in the dependency map according to the DEPENDSON attributes of the group and server. The process can then check if loops and other DEPENDSON errors exist. The process can then add the server from the map_start node to its runnable list. The process then invokes the servers in the available list in asynchronous mode and gets the response information from the pipe. When the process receives one response, it checks whether it can start the dependent server. If so, add the subordinate server to the runnable list and continue launching processes in the runnable list. Finally, after booting all servers, tmboot exits.

Creating a Dependency Map According to one embodiment, an exemplary process can create a dependency map, for example, according to the following exemplary procedure.

Parallel Launch in Local Mode According to one embodiment, a process may support parallel launch in local mode. Below is an example of such a process.

For Unix (registered trademark)
The tmboot process creates an anonymous pipe, forks the server process, and sends pipe fd to the server process.

The server process completes tpsrvinit and sends the response over the pipe to tmboot.
When tmboot reads the pipe in non-blocking mode and gets a response, it checks the dependency map to determine which server to boot next.

For Windows (registered trademark)
The tmboot process creates named pipes and forks server processes. After the server completes tpsrvinit, it opens the named pipe, connects, and sends the response over the named pipe to tmboot.

tmboot creates one thread and waits for pipe information. If it gets a response, it checks the dependency map to determine which server to start next.

SHM Mode According to one embodiment, parallel activation can be supported in SHM mode. In SHM mode, tmboot starts all servers in the executable list and waits for responses from the started servers. The server sends the response over the pipe to the tmboot process. The tmboot process receives the response and runs the next job. Tmboot prepares to boot the servers in the runnable list in asynchronous mode and collect responses from the booted servers. If the server receives one response, it checks whether the dependent server is ready. If ready, add the server to the executable list and start it.

Parallel Activation in MP Mode According to one embodiment, parallel activation can be supported in MP mode. In MP mode, tmboot and tlisten can create another thread that exchanges information with each other. This local thread can wait for messages to be sent from the remote machine. Notifies the main thread to continue if there are servers started remotely. A remote tlisten thread prepares to collect responses from the spawned server. When one server starts or fails, it notifies local threads via network messages.

Many features of the present invention can be implemented in or using or with the aid of hardware, software, firmware, or a combination thereof. Thus, a processing system (eg, including one or more processors) can be used to implement features of the present invention.

Many features of the present invention can be implemented in, or implemented using, or with the assistance of a computer program product. The computer program product is a storage medium or computer readable medium storing instructions that can be used to program a processing system to perform any of the features described herein. The storage medium may be any type of disk, ROM, RAM, EPROM, EEPROM, DRAM, VRAM, flash memory, including floppy disks, optical disks, DVDs, CD-ROMs, microdrives, and magneto-optical disks. It may include, but is not limited to, devices, magnetic or optical cards, nanosystems (including molecular memory ICs), or any type of medium or apparatus suitable for storing instructions and/or data.

A feature of the invention is software that, when stored on any machine-readable medium, controls the hardware of a processing system and uses the results of the invention to enable the processing system to interact with other mechanisms. and/or embedded in firmware. Such software or firmware may include, but is not limited to application code, device drivers, operating systems and execution environments/containers.

Aspects of the invention may also be implemented in hardware, for example, using hardware elements such as an application specific integrated circuit (ASIC). Implementation of a hardware state machine to perform the functions described in this disclosure will be apparent to those skilled in the art.

Additionally, the present invention may be applied to any one or more conventional general or special purpose digital computers, computing devices, machines, or microcontrollers, including one or more processors, memory and/or computer readable storage media programmed according to the teachings of this disclosure. It can be conveniently implemented using a processor. Appropriate software coding can be readily prepared by skilled programmers based on the teachings of the present disclosure, as will be apparent to those skilled in the software art.

While various embodiments of the present invention have been described above, it should be understood that these embodiments are presented by way of illustration and not limitation. It will be apparent 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.

The present invention has been described using functional building blocks that illustrate the performance of specific functions and their relationships. The boundaries of these functional building blocks are generally arbitrarily defined in this disclosure for convenience of explanation. Alternatively, functions illustrated to be performed by separate elements may be performed by a single element. Alternate boundaries may be defined so long as the specified functions and relationships thereof are appropriately performed. Any of these alternative boundaries are therefore within the scope and spirit of the invention.

The foregoing description of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. The breadth and scope of the invention should not be limited by any of the above illustrative embodiments. Numerous modifications and variations will be apparent to those skilled in the art. Modifications and variations include any possible combination of the disclosed features. The embodiments best illustrate the principles of the invention and its practical application so that others skilled in the art can understand the invention according to its various embodiments and variations suitable for the particular application contemplated. are selected and described as follows. It is intended that the scope of the invention be defined by the claims appended hereto and their equivalents.

Claims (11)

A method for parallel startup of application servers in a transaction processing environment, comprising:
loading into memory a plurality of server entries and a plurality of group entries, each of the plurality of server entries being associated with one server of a plurality of servers, each of the plurality of group entries being associated with a plurality of Associated with one of the server groups, and
creating a dependency map between the plurality of server entries and the plurality of group entries;
checking for non-dependent servers among the plurality of servers;
creating an executable list that includes servers that do not have the dependencies;
and starting each server in parallel among the plurality of servers that does not have a dependency relationship based on the executable list;
The step of starting each server in parallel that does not have a dependency among the plurality of servers,
while executing the transaction processing environment in shared memory (SHM) mode, a boot process module launching each of the independent servers in the plurality of servers in parallel;
the boot process module creating a pipe to communicate with each of the non-dependency servers in the plurality of servers;
each non-dependent server in the plurality of servers sending a response to the boot process module over the pipe ;
The method further comprises:
initializing each server having no dependencies among the plurality of servers;
receiving response information from each of the spawned servers;
a step of determining whether or not a dependent server can be activated each time one piece of the response information is received;
including the dependent server in the executable list based on the dependent server being bootable;
and starting any remaining not-yet-started servers according to said dependency map and said executable list. The step of creating the dependency map includes:
checking dependency attributes of each of the plurality of server entries and the plurality of group entries;
and creating the dependency map based on each dependency attribute discovered during the checking. checking the dependency map for dependency loops;
3. The method of claim 1 or 2 , further comprising, if a dependency loop is found, recreating the dependency map so as to avoid the found dependency loop. Further comprising checking whether each server having no dependency among the plurality of servers started in parallel has been started before starting the remaining not-started servers according to the created dependency map; The method according to any one of claims 1-3 . A method according to any preceding claim, wherein each of said plurality of servers comprises a Tuxedo application server. A system for starting application servers in parallel in a transaction processing environment,
one or more microprocessors;
a processing unit operating on the one or more microprocessors, the processing unit, when operating,
loading into memory a plurality of server entries and a plurality of group entries, each of the plurality of server entries being associated with one of a plurality of servers, each of the plurality of group entries being associated with a plurality of is associated with one of the server groups in
creating a dependency map between the plurality of server entries and the plurality of group entries;
checking for non-dependent servers among the plurality of servers;
creating an executable list that includes servers that do not have the dependencies;
starting each server in parallel among the plurality of servers that does not have a dependency relationship based on the executable list;
The step of starting each server in parallel that does not have a dependency among the plurality of servers,
while executing the transaction processing environment in shared memory (SHM) mode, a boot process module launching each of the independent servers in the plurality of servers in parallel;
the boot process module creating a pipe to communicate with each of the non-dependency servers in the plurality of servers;
each non-dependent server in the plurality of servers sending a response to the boot process module over the pipe ;
initializing each server having no dependencies among the plurality of servers;
receiving response information from each of the spawned servers;
a step of determining whether or not a dependent server can be activated each time one piece of the response information is received;
including the dependent server in the executable list based on the dependent server being bootable;
starting the remaining unstarted servers according to the created dependency map. The step of creating the dependency map includes:
checking dependency attributes of each of the plurality of server entries and the plurality of group entries;
and creating the dependency map based on each dependency attribute discovered during the checking. checking the dependency map for dependency loops;
8. The system of claim 6 or 7 , further comprising, if a dependency loop is found, recreating the dependency map so as to avoid the found dependency loop. Further comprising checking whether each server having no dependency among the plurality of servers started in parallel has been started before starting the remaining not-started servers according to the created dependency map; A system according to any of claims 6-8 . A system according to any one of claims 6 to 9 , wherein each of said plurality of servers comprises a Tuxedo application server. A program for causing one or more processors to execute the method according to any one of claims 1 to 5 .

Images