JP6943089B2 - Information processing system, information processing method, and program - Google Patents

Description

The present invention relates to an information processing system, an information processing method, and a program, and more particularly to an information processing system, an information processing method, and a program for updating an application.

An application running on an application server may be required to operate continuously 24 hours a day, 365 days a year. On the other hand, when updating an application to fix a defect or extend a function, it is generally necessary to stop the application.

As an example of the method of continuing the operation of the application at the time of updating, there is a method of running the application before the change and the application after the change at the same time and switching the distribution destination of the request from the application before the change to the application after the change. Patent Document 1 discloses a method of switching an application for each session in order to maintain consistency of processing within the session when processing is performed for a session composed of a plurality of requests. That is, the session request processed before the change is distributed to the application before the change, and the request for the new session after the change is distributed to the application after the change. In this method, by monitoring the number of sessions, the application can be automatically undeployed when the number of sessions becomes 0.

On the other hand, an application may consist of a plurality of modules. For example, an application deployed on a Java® EE (Enterprise Edition) application server can consist of a plurality of modules. Specifically, the application deployed on the Java EE application server is a Web module that accepts requests from the Web browser of the client terminal, an EJB (Enterprise JavaBeans) module that executes back-end processing, and an EJB module that is called from there. Can be configured from. In an application composed of multiple modules in this way, if there is no change in the interface for calling the module and only the module execution content is changed, the change is made without updating the module that calls the changed module. Only the modules that existed can be updated.

Patent Document 2 states that when an application is composed of a plurality of modules, when the module is updated, the module that calls the updated module is also newly loaded and the updated module is called. A method of executing processing recursively to a calling module is disclosed. By this method, in Patent Document 2, even when a part of the modules of the application composed of a plurality of modules are updated, only the modules that directly accept the request are sorted by using the session ID before the update. Requests for started sessions will be processed by the module before the update, and new requests after the update will be processed by the module after the update. Therefore, it is possible to reflect the module update for a new request without causing inconsistency in the processing for the session before the update.

Japanese Patent No. 4532946 Japanese Unexamined Patent Publication No. 2017-16517

However, Patent Document 2 does not consider the release of the deployment, and there is a problem that the old module remains as it is even if it is no longer used. Further, in Patent Document 1, the case where the application is composed of a plurality of modules is not considered, and there is a problem that only a part of the modules cannot be released.

The present invention has been made to solve such a problem, and an object of the present invention is to provide an information processing system, an information processing method, and a program capable of automatically undeploying an unnecessary module. And.

The information processing system according to the first aspect of the present invention monitors the number of sessions for each of the plurality of modules constituting the application, and when the number of sessions of the first module that directly accepts the request becomes 0, A session information monitoring means that outputs a undeployment request, and a module deployment that undeploys the first module and undeploys a module that is no longer called by any module when the undeployment request is received. It is provided with a release means.

The information processing method according to the second aspect of the present invention monitors the number of sessions for each of the plurality of modules constituting the application, and when the number of sessions of the first module that directly accepts the request becomes 0, The first module is undeployed, and the module that is no longer called by any module is undeployed.

The program according to the third aspect of the present invention monitors the number of sessions for each of the plurality of modules constituting the application on the processor, and when the number of sessions of the first module that directly accepts the request becomes 0. , The first module is undeployed, and the module that is no longer called by any module is undeployed, so that the process is executed.

INDUSTRIAL APPLICABILITY According to the present invention, it is possible to provide an information processing system, an information processing method, and a program capable of automatically undeploying an unnecessary module.

It is a block diagram which shows the configuration example of the application server which concerns on Embodiment 1. FIG. It is a flowchart which shows the processing example of the application server which concerns on Embodiment 1. FIG. It is a block diagram which shows the configuration example of the execution environment of the application which concerns on Embodiment 2. FIG. It is a figure which shows the example of the execution file table which concerns on Embodiment 2. FIG. It is a figure which shows the structure of the load module loaded in the module execution part which concerns on Embodiment 2. FIG. It is a figure which shows the example of the version table which concerns on Embodiment 2. It is a figure which shows the example of the load version table which concerns on Embodiment 2. FIG. It is a figure which shows the example of the call relation table which concerns on Embodiment 2. FIG. It is a figure which shows the example of the session table which concerns on Embodiment 2. FIG. It is a figure which shows the example of the session information table which concerns on Embodiment 2. FIG. It is a figure which shows the example of the session object which concerns on Embodiment 2. FIG. It is a flowchart which shows the acquisition process of the session which concerns on Embodiment 2. It is a flowchart which shows the update process of the session which concerns on Embodiment 2. It is a flowchart which shows the deletion process of the session performed by the deletion request by the load module which concerns on Embodiment 2. FIG. It is a flowchart which shows the deletion process of the session performed by the time-out which concerns on Embodiment 2. FIG. 5 is a flowchart showing a process when the session information monitoring unit according to the second embodiment receives a notification of session deletion. FIG. 5 is a flowchart showing a process when the module deployment release unit according to the second embodiment receives a module deployment release request. FIG. 5 is a flowchart showing a process when the module deployment release unit according to the second embodiment receives a module deployment release request. It is a figure which shows the example of the calling relation between modules which concerns on Embodiment 2. FIG. It is a figure which shows the example of the call relation between the load modules which concerns on Embodiment 2. FIG. It is a figure which shows the example of the load version table in which the row which concerns on Embodiment 2 is deleted. It is a figure which shows the example of the call relation table in which the row which concerns on Embodiment 2 is deleted. It is a figure which shows the example of the call relation between the load modules in which A'(3, 3) is undeployed from the state of FIG. 20 which concerns on Embodiment 2. FIG. It is a figure which shows the example of the execution file table in which the line which concerns on Embodiment 2 is deleted. It is a figure which shows the example of the load version table in which the row which concerns on Embodiment 2 is further deleted. It is a figure which shows the example of the call relation table in which the row which concerns on Embodiment 2 is further deleted. FIG. 5 is a diagram showing an example of a call relationship between load modules in which A (2,1), B (2,1), and C'(2,2) are undeployed from the state of FIG. 23 according to the second embodiment. .. It is a block diagram which shows the other configuration example of the execution environment of the application which concerns on Embodiment 2. FIG. It is a block diagram which shows the configuration example of the execution environment of the application which concerns on Embodiment 3. FIG.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. In each drawing, the same or corresponding elements are designated by the same reference numerals, and duplicate explanations are omitted as necessary for the sake of clarity of explanation.

Embodiment 1
First, a configuration example of the application server 100 according to the first embodiment of the present invention will be described with reference to the block diagram of FIG. The application server 100 includes a session information monitoring unit 110 and a module deployment release unit 120. The application server 100 is an embodiment of the information processing system of the present invention.

The session information monitoring unit 110 monitors the number of sessions for each of a plurality of program modules (hereinafter, simply referred to as modules) constituting the application. Further, the session information monitoring unit 110 outputs a deployment release request to the module deployment release unit 120 when the number of sessions of the first module that directly accepts the request becomes 0. The first module is a module that directly receives a request from a client terminal (not shown).

The module deployment release unit 120 receives a deployment release request from the session information monitoring unit 110. Further, when the module deployment release unit 120 receives the deployment release request, the first module is undeployed, and the module that is no longer called by any module is undeployed.

The module deployment release unit 120 may recursively release the module that is no longer called by any module. Recursively undeploying a module means, for example, when the number of sessions of the first module becomes 0, the second module that is no longer called by any module is undeployed. It is a process of undeploying a third module that is no longer called by any module by undeploying the second module. This makes it possible to automatically undeploy all modules that are no longer needed.

The latest version of the module may be excluded from the target of undeployment. That is, the session information monitoring unit 110 may not output the deployment release request when the module version of the first module in which the number of sessions has become 0 is the latest module version. Further, the module undeployment unit 120 may not undeploy the module when the module version of the module that is no longer called from any module is the latest module version. As a result, the first module of the latest module version can accept new requests even after the number of sessions becomes zero. In addition, it is possible to prevent the module that has just been deployed from being undeployed.

Subsequently, a processing example of the application server 100 according to the first embodiment will be described with reference to the flowchart of FIG.

First, the application server 100 monitors the number of sessions for each of the plurality of modules constituting the application by the session information monitoring unit 110 (step S101).

Next, when the number of sessions of the first module that directly accepts the request becomes 0, the application server 100 disdeploys the first module by the module deployment release unit 120, and thereby, from which module. Also undeploys the module that is no longer called (step S102).

As described above, the application server 100 (information processing system) according to the first embodiment of the present invention is configured to include a session information monitoring unit 110 and a module deployment release unit 120. Further, the application server 100 is configured to monitor the number of sessions for each of a plurality of modules constituting the application by the session information monitoring unit 110. Further, when the number of sessions of the first module that directly accepts the request becomes 0, the application server 100 undeploys the first module by the module deployment release unit 120, and thereby from any module. It is configured to undeploy the module that is no longer called. As a result, in the application server 100 according to the first embodiment, the unnecessary modules can be automatically undeployed.

Embodiment 2
Subsequently, a second embodiment of the present invention will be described. FIG. 3 is a block diagram showing a configuration example of an application execution environment according to the second embodiment of the present invention. Referring to FIG. 3, the execution environment includes an application server 100A, a management terminal 200, and a client terminal 300. The management terminal 200 and the client terminal 300 are connected to the application server 100A via the network 10.

The management terminal 200 executes an operation operation such as deploying an application on the application server 100A.

The client terminal 300 transmits a request related to application processing to the application server 100A.

The application server 100A receives a request from the client terminal 300 and executes application processing. The application server 100A is an embodiment of the information processing system of the present invention.

The application server 100A includes a session information monitoring unit 110A, a module deployment release unit 120A, a deployment processing unit 130, a module generation unit 140, a module execution unit 150, a request distribution unit 160, a session information management unit 170, and the like. It includes a module storage unit 181, a call-related storage unit 182, a version information storage unit 183, and a session distribution destination information storage unit 184.

The deployment processing unit 130 deploys each of the plurality of modules constituting the application to the application server 100A by the operation operation from the management terminal 200. Specifically, the deployment processing unit 130 registers information about the module received from the management terminal 200 in the execution file table 1 of the module storage unit 181. Further, the deployment processing unit 130 stores the actual execution file received from the management terminal 200 in the module storage unit 181.

The module storage unit 181 stores the module deployed by the deployment processing unit 130. Specifically, the module storage unit 181 stores the executable file table 1 and the substance of the executable file. The executable file table 1 shows the executable files of each of the plurality of modules constituting the application. An example of the executable file table 1 is shown in FIG. In the executable file table 1, each module name of the plurality of modules is associated with the version (file version) of the executable file of the module and the file name.

The module generation unit 140 loads the module stored in the module storage unit 181 into the module execution unit 150 as the load module 400. Specifically, the module generation unit 140 generates the processing execution unit 401 using the execution file, and sets it in the load module 400 together with the generated calling unit 402. Further, the module generation unit 140 loads the generated load module 400 into the module execution unit 150. Further, the module generation unit 140 registers the version information storage unit 183 in the version table 2 and the load version table 3. Further, the module generation unit 140 registers the call relation storage unit 182 in the call relation table 4.

FIG. 5 is a diagram showing a configuration of a load module 400 loaded on the module execution unit 150 according to the second embodiment. The load module 400 includes a processing execution unit 401 and a calling unit 402.

The process execution unit 401 executes the process related to the module according to the execution file of the module. The calling unit 402 calls the processing of the load module 400 of another module on which the module depends. If a module depends on a plurality of other modules, there is a caller 402 for each other module.

The module execution unit 150 executes the load module 400 loaded by the module generation unit 140.

The version information storage unit 183 stores the version table 2 and the load version table 3. Version table 2 shows the latest load module 400 for each module. The load version table 3 shows each load module 400 loaded in the module execution unit 150.

An example of the version table 2 is shown in FIG. In the version table 2, the latest load module 400 version (module version) of the module is associated with each module name of the plurality of modules.

An example of the load version table 3 is shown in FIG. In the load version table 3, the module version of the load module 400 of the module and the file version of the executable file are associated with each module name of the plurality of modules.

The call relation storage unit 182 stores the call relation table 4. Call relationship table 4 shows the call relationship between modules. An example of the call relation table 4 is shown in FIG. In the call relation table 4, the module name and module version pair of the calling module are associated with the module name and module version pair of the called destination module.

The session distribution destination information storage unit 184 stores the session table 5. The session table 5 shows the load module 400 to which each session is distributed. An example of the session table 5 is shown in FIG. In the session table 5, the module name of the module is associated with the session ID (Identifier) of the session for the module and the module version of the load module 400 to be distributed.

The request distribution unit 160 distributes the request received from the client terminal 300 to the appropriate load module 400 based on the session table 5. Further, the request distribution unit 160 registers the session ID, the module name, and the module version in the session table 5.

The session information management unit 170 has a session information table 6 that records the session ID, the session object, and the last access time to the session. An example of the session information table 6 is shown in FIG. The session object is, for example, a structure composed of a key / value pair as shown in FIG. 11, but is not limited thereto.

The processes of the session information monitoring unit 110A, the module deployment release unit 120A, and the session information management unit 170 will be specifically described later with reference to a flowchart.

The application server 100A may be a computer operated by control based on a program. That is, the application server 100A may include a processor such as a CPU (Central Processing Unit) and a storage medium for storing a program related to processing of each functional unit, and cause the processor to execute the program. Further, each component of the application server 100A may be distributed and arranged in different computers connected by wire or wirelessly. Further, each component of the application server 100A may be an independent logic circuit.

Subsequently, the operation of the second embodiment will be described.

<Access processing for session information>
First, the access process for session information will be described. The session associated with the session ID can be acquired / updated / deleted by the process executed by the process execution unit 401 of the load module 400.

FIG. 12 is a flowchart showing a session acquisition process according to the second embodiment.

The load module 400 requests the session information management unit 170 for a session object corresponding to the session ID included in the request. That is, the session information management unit 170 is requested by the load module 400 for the session object corresponding to the session ID included in the request (step S201).

Next, the session information management unit 170 determines whether or not there is a row of the requested session ID in the session information table 6 (step S202).

When there is a row of the requested session ID (YES in step S202), the session information management unit 170 acquires the session object corresponding to the requested session ID from the session information table 6 and the session information table 6 The last access time of the row of the requested session ID in is updated to the current time (step S203).

On the other hand, when there is no row for the requested session ID (NO in step S202), the session information management unit 170 newly generates a session object, and sets the session ID, the session object, and the current time in the session information table. Add to 6 (step S204).

After step S203 or step S204, the session information management unit 170 returns the acquired or newly generated session object to the load module 400 (step S205).

FIG. 13 is a flowchart showing a session update process according to the second embodiment.

The load module 400 acquires the session object corresponding to the session ID by the session acquisition process (step S301).

Next, the load module 400 updates the contents of the acquired session object (step S302).

Next, the load module 400 sends the session ID and the updated session object to the session information management unit 170 and requests the update (step S303).

Next, the session information management unit 170 updates the session object in the row corresponding to the session ID requested in the session information table 6, and updates the last access time to the current time (step S304).

Next, the deletion of the session will be described. The session may be deleted by a deletion request by the load module 400, or may be automatically deleted after a certain period of time has elapsed from the last access time of the session (session timeout). If there is a configuration of only one of them and there is no session timeout, the last access time of the session information table 6 and its update process are unnecessary.

FIG. 14 is a flowchart showing a session deletion process performed by a deletion request by the load module 400 according to the second embodiment.

The load module 400 requests the session information management unit 170 to delete the session corresponding to the session ID. That is, the session information management unit 170 is requested by the load module 400 to delete the session corresponding to the session ID (step S401).

Next, the session information management unit 170 deletes the row corresponding to the session ID requested in the session information table 6 (step S402).

Next, the session information management unit 170 notifies the session information monitoring unit 110A of the session ID of the deleted session (step S403).

FIG. 15 is a flowchart showing a session deletion process performed by the timeout according to the second embodiment. The process of FIG. 15 ends when the application server 100A is stopped.

If there is a session in the session information table 6 for which a predetermined time (timeout time) has elapsed from the last access time, the session information management unit 170 deletes the row (step S501). Specifically, the session information management unit 170 compares the last access time in the session information table 6 with the current time, and if there is a session for which a predetermined timeout time has elapsed from the last access time, deletes the line.

Next, the session information management unit 170 notifies the session information monitoring unit 110A of the session ID of the deleted session (step S502).

Next, the session information management unit 170 determines whether or not a predetermined time (monitoring interval) has elapsed from the time when step S501 is performed (step S503).

If the predetermined monitoring interval has not elapsed (NO in step S503), the session information management unit 170 waits for the predetermined monitoring interval to elapse.

When the predetermined monitoring interval has elapsed (YES in step S503), the session information management unit 170 performs the process of step S501 again.

The time until time-out (time-out time) may be the same or different for all modules or sessions. When changing the time-out time for each module or session, for example, a time-out time column is added to the session information table 6, and the time-out time is compared with the elapsed time from the last access time in step S501. You may do so.

<Processing when receiving session deletion notification>
Subsequently, using the flowchart of FIG. 16, the process when the session information monitoring unit 110A receives the session deletion notification from the session information management unit 170 will be described.

The session information monitoring unit 110A receives a session deletion notification including the session ID of the deleted session from the session information management unit 170 (step S601).

Next, the session information monitoring unit 110A acquires the module name M and the module version V of the row distribution destination that matches the session ID of the deleted session from the session table 5 of the session distribution destination information storage unit 184 (step). S602).

Next, the session information monitoring unit 110A deletes the row matching the session ID of the deleted session from the session table 5 (step S603).

Next, the session information monitoring unit 110A determines whether or not there is a row in the session table 5 in which the module name is M and the module version is V (step S604).

When there is a row in the session table 5 in which the module name is M and the module version is V (YES in step S604), the session information monitoring unit 110A ends the process. As a result, if the number of sessions is not 0, the process is terminated.

On the other hand, when there is no row in the session table 5 where the module name is M and the module version is V (NO in step S604), the session information monitoring unit 110A sets the latest module version of the module name M in the version table 2. Obtained from (step S605).

Next, the session information monitoring unit 110A determines whether or not the latest module version acquired in step S605 matches the module version V (step S606).

When the latest module version matches the module version V (YES in step S606), the session information monitoring unit 110A ends the process. As a result, the latest version of the module will not be subject to dedeployment.

On the other hand, when the latest module version does not match the module version V (NO in step S606), the session information monitoring unit 110A outputs a module deployment release request of the module name M and the module version V to the module deployment release unit 120A. (Step S607). As a result, when the number of sessions of the old module version (module version that is not the latest module version) becomes 0, the module deployment release request of the module name M and module version V is made from the session information monitoring unit 110A. It is output to the release unit 120A.

<Module deployment release process>
Subsequently, the process when the module deployment release unit 120A receives the module deployment release request will be described with reference to the flowcharts of FIGS. 17 and 18.

The module deployment release unit 120A receives a module deployment release request of the module name M and the module version V from the session information monitoring unit 110A (step S701).

Next, the module deployment release unit 120A deletes the module having the module name M and the module version V from the module execution unit 150 (step S702).

Next, the module deployment release unit 120A acquires the file version FV of the module having the module name M and the module version V from the load version table 3 (step S703).

Next, the module deployment release unit 120A deletes the row of the module name M and the module version V from the load version table 3 (step S704).

Next, the module deployment release unit 120A determines whether or not there is a line in the load version table 3 where the module name is M and the file version is FV (step S705).

If there is a line in the load version table 3 where the module name is M and the file version is FV (YES in step S705), steps S706 to S708 are skipped and the process proceeds to step S709.

On the other hand, when there is no line in the load version table 3 where the module name is M and the file version is FV (NO in step S705), the module deployment release unit 120A matches the module name M and the file version FV. The file name F of the line to be executed is acquired from the executable file table 1 (step S706).

Next, the module deployment release unit 120A deletes the line matching the module name M and the file version FV from the executable file table 1 (step S707).

Next, the module deployment release unit 120A deletes the entity of the executable file F from the module storage unit 181 (step S708).

Next, the module deployment release unit 120A acquires a row in which the caller module name is M and the caller module version is V from the call relationship table 4 of the call relationship storage unit 182 (step S709). It is assumed that the call destination called from the module having the module name M and the module version V is the module name S and the module version SV.

Next, the module deployment release unit 120A deletes the row whose caller module name is M and whose caller module version is V from the call relation table 4 (step S710).

Next, the module deployment release unit 120A repeats the following processing for the number of modules called by the module having the module name M and the module version V (step S711). That is, the following processing is executed for each row acquired in step S709.

The module deployment release unit 120A determines whether or not there is a row in the call relationship table 4 of the call relationship storage unit 182 where the module name of the call destination is S and the module version of the call destination is SV (step S712). ).

If there is a row in the call-related table 4 where the module name of the callee is S and the module version of the callee is SV (YES in step S712), steps S713 to S715 are skipped and loop processing is performed. The process proceeds to the end (step S716). As a result, the undeployment request is not issued for the module called from other modules.

On the other hand, when there is no row in the call-related table 4 where the module name of the callee is S and the module version of the callee is SV (NO in step S712), the module deployment release unit 120A has the module name S. The latest module version is acquired from the version table 2 (step S713).

Next, the module deployment release unit 120A determines whether or not the latest module version acquired in step S713 matches the module version SV (step S714).

If the latest module version matches the module version SV (YES in step S714), step S715 is skipped and the process proceeds to the end of the loop process (step S716). As a result, the latest version of the module will not be subject to dedeployment.

On the other hand, when the latest module version does not match the module version SV (NO in step S714), the module deployment release unit 120A issues a module deployment release request with the module name S and the module version SV (step S715). This makes it possible to issue a dedeployment request for an older module version (a module version that is not the latest module version) that is no longer called by other modules.

The module deployment release unit 120A repeats the above processing (processing in the loop) until the processing for each row acquired in step S709 is completed (step S716).

As described above, the module deployment release request is issued from the session information monitoring unit 110A when the number of sessions becomes 0. Further, the module deployment release request is recursively issued from the module deployment release unit 120A to the module that is no longer called from other modules.

<Specific example>
Subsequently, a specific example of the operation of the second embodiment of the present invention will be described.

FIG. 19 is a diagram showing an example of a calling relationship between modules according to the second embodiment of the present invention. Here, it is assumed that the application is composed of four modules A, B, C, and D, as shown in FIG. Further, as shown in FIG. 19, it is assumed that the client terminal 300 calls the module A, the module A calls the module B, the module B calls the module C, and the module C calls the module D.

Further, it is assumed that module A: "A.war", module B: "B.jar", module C: "C.jar", and module D: "D.jar" exist as executable files of each module. Further, as the updated (changed) executable file of each module, module A': "A-modified.war", module C': "C-modified.jar", module C ":" C-modified-2 ". .Jar "assumed to exist. Here, "'" assigned to the module name indicates a module whose executable file has been changed.

First, it is assumed that the states of the executable file table 1, the version table 2, the load version table 3, and the call-related table 4 are FIG. 4, FIG. 6, FIG. 7, and FIG. 8, respectively. In this case, the calling relationship between the load modules 400 is as shown in FIG. Note that "a (b, c)" given to the load module 400 indicates the load module 400 of the module a and the module version b, and that the load module 400 uses the executable file of the file version c. show.

When a deployment release request for module A and module version 3 (A'(3,3)) is issued from the state of FIG. 20, A'(3,3) is undeployed. However, even if A'(3,3) is undeployed, module B and module version 2 (B (2,1)) are called from module A and module version 2 (A (2,1)). Therefore, B (2, 1) is not undeployed.

The transition of the table and the release of the deployment at this time will be described with reference to the steps of FIGS. 17 and 18. In step S704 of FIG. 17, the row with the module name A and the module version 3 is deleted from the load version table 3. As a result, the load version table 3 becomes as shown in FIG. Further, in step S710 of FIG. 18, the row having the calling module name A and the calling module version 3 is deleted from the calling relation table 4. As a result, the call relation table 4 becomes as shown in FIG. Further, the calling relationship between the load modules 400 at this time is as shown in FIG.

When a deployment release request for module A and module version 2 (A (2,1)) is issued from the state of FIG. 23, A (2,1) is undeployed. Further, since A (2,1) is undeployed, module B and module version 2 (B (2,1)) are not called from any module, so that the deployment to B (2,1) is undeployed. Requests are made recursively and B (2,1) is undeployed.

The transition of the table and the release of the deployment at this time will be described with reference to the steps of FIGS. 17 and 18. In step S704 of FIG. 17, the row with the module name A and the module version 2 is deleted from the load version table 3. Further, in step S710 of FIG. 18, the row having the calling module name A and the calling module version 2 is deleted from the calling relation table 4. As a result, there is no row in the call relation table 4 where the call destination module name is B and the call destination module version is 2. Further, the latest module version of the module name B in the version table 2 is 3, which does not match the called module version 2. Therefore, in step S715 of FIG. 18, a request for undeployment is issued for the module name B and the module version 2 (B (2, 1)), and B (2, 1) is undeployed.

Further, due to the undeployment of B (2,1), the module name C and the module version 2 (C'(2,2)) will not be called from any module. Therefore, the undeployment request for C'(2,2) is recursively issued, and C'(2,2) is undeployed.

The transition of the table and the release of the deployment at this time will be described with reference to the steps of FIGS. 17 and 18. In step S704 of FIG. 17, the row with the module name B and the module version 2 is deleted from the load version table 3. Further, in step S710 of FIG. 18, the row having the calling module name B and the calling module version 2 is deleted from the calling relation table 4. As a result, there is no row in the call relation table 4 where the call destination module name is C and the call destination module version is 2. Further, the latest module version of the module name C in the version table 2 is 3, which does not match the called module version 2. Therefore, in step S715 of FIG. 18, a request for undeployment is issued for the module name C and the module version 2 (C'(2,2)), and C'(2,2) is undeployed.

In the undeployment for module name C and module version 2 (C'(2,2)), the row with module name C and module version 2 is deleted from the load version table 3 by step S704 in FIG. As a result, there is no line in the load version table 3 having the module name C and the file version 2. Therefore, according to step S707 in FIG. 17, the line having the module name C and the file version 2 is from the executable file table 1. Will be deleted. Further, in step S708 of FIG. 17, the substance of the executable file having the module name C and the file version 2 is deleted from the module storage unit 181. Further, in step S710 of FIG. 18, the row having the calling module name C and the calling module version 2 is deleted from the calling relation table 4.

As a result, the states of the executable file table 1, the load version table 3, and the call relation table 4 are as shown in FIGS. 24, 25, and 26, respectively. Further, the calling relationship between the load modules 400 at this time is as shown in FIG. 27.

As described above, the application server 100A (information processing system) according to the second embodiment of the present invention is further provided with the session information management unit 170. Further, the session information management unit 170 is configured to notify the session information monitoring unit 110A of the session ID of the session requested to be deleted or the session in which a predetermined time has elapsed from the last access time. As a result, in the application server 100A according to the second embodiment, the session information monitoring unit 110A can determine the session ID of the session to be deleted.

Further, the application server 100A is further provided with a session distribution destination information storage unit 184 for storing the session table 5. Further, the session table 5 has a configuration in which the session ID of the session for the module and the module version of the distribution destination load module 400 are associated with the module name. Further, the session information monitoring unit 110A is configured to determine whether or not the number of sessions of the first module has become 0 based on the session ID and the session table 5 notified from the session information management unit 170. As a result, in the application server 100A according to the second embodiment, it is determined whether or not the number of sessions of the first module has become 0 by using the notification of the session ID from the session information management unit 170 as a trigger. Can be done.

Further, in the application server 100A, when the number of sessions of the first module becomes 0, the session information monitoring unit 110A makes a deployment release request including the module name and the module version of the first module to the module deployment release unit 120A. It is configured to output to. Further, in the application server 100A, when the module deployment release unit 120A receives the deployment release request, the module name and the first module of the module version included in the deployment release request are undeployed, and thereby from which module. Is configured to undeploy the module with the module name and module version that is no longer called. As a result, the application server 100A according to the second embodiment can be undeployed for each module version.

In the above description, the registration of data in each table of the module storage unit 181, the call-related storage unit 182, the version information storage unit 183, and the session distribution destination information storage unit 184 is performed by the deployment processing unit 130 and the module generation unit. It is assumed that the operation is performed using the 140 and the request distribution unit 160, but the present invention is not limited to this. For example, as shown in FIG. 28, the application server 100A may not include the deployment processing unit 130, the module generation unit 140, and the request distribution unit 160. In this case, the data of each table of the module storage unit 181, the call-related storage unit 182, the version information storage unit 183, and the session distribution destination information storage unit 184 is registered from the management terminal 200 by, for example, the operation manager. You may.

Further, in the above description, the case where the number of sessions of the first module that directly accepts the application request becomes 0 as the trigger for the deployment release is described, but the present invention is not limited to this. For example, the operation manager may explicitly issue a deployment release request to the module deployment release unit 120A through the management terminal 200. That is, the application server 100A receives the deployment release request of the first module from the management terminal 200, and the module deployment release unit 120A disdeploys the first module by the deployment release request received from the management terminal 200. It may also have a function to undeploy a module that is no longer called by any module. As a result, the operation manager can undeploy the module at an arbitrary timing, and the module that is no longer needed can be automatically undeployed accordingly.

Embodiment 3
Subsequently, the third embodiment of the present invention will be described. FIG. 29 is a block diagram showing a configuration example of an application execution environment according to the third embodiment of the present invention. Referring to FIG. 29, the execution environment includes an application server 100B and a management terminal 200. The management terminal 200 is connected to the application server 100B via the network 10.

The application server 100B includes a module deployment release unit 120B, a module execution unit 150, a module storage unit 181, a call-related storage unit 182, and a version information storage unit 183.

The application server 100B does not have the function of undeploying the module when the number of sessions of the first module that directly receives the application request becomes 0, which is described in the second embodiment. Instead of that function, the application server 100B has a function of undeploying the module in response to the undeployment request received from the management terminal 200. That is, the application server 100B receives the deployment release request of the first module from the management terminal 200. Further, the module deployment release unit 120B releases the deployment of the first module in response to the deployment release request received from the management terminal 200. Further, the module undeployment unit 120B undeploys the module that is no longer called by any module due to the undeployment of the first module. As a result, the operation manager can undeploy the module at an arbitrary timing, and the module that is no longer needed can be automatically undeployed accordingly.

In the above example, the program can be stored and supplied to a computer using various types of non-transitory computer readable medium. Non-transient computer-readable media include various types of tangible storage media. Examples of non-temporary computer-readable media include magnetic recording media (eg, flexible disks, magnetic tapes, hard disk drives), magneto-optical recording media (eg, magneto-optical disks), CD-ROMs (Read Only Memory), CD-Rs. CD-R / W, semiconductor memory (for example, mask ROM, PROM (Programmable ROM), EPROM (Erasable PROM), flash ROM, RAM (Random Access Memory)) are included. The program may also be supplied to the computer by various types of transient computer readable medium. Examples of temporary computer-readable media include electrical, optical, and electromagnetic waves. The temporary computer-readable medium can supply the program to the computer via a wired communication path such as an electric wire and an optical fiber, or a wireless communication path.

Although the present invention has been described above with reference to the embodiments, the present invention is not limited to the above embodiments. Various changes that can be understood by those skilled in the art can be made within the scope of the invention in the configuration and details of the invention of the present application.

5 Session table 100, 100A Application server (information processing system)
110, 110A Session information monitoring unit 120, 120A Module deployment release unit 170 Session information management unit 184 Session distribution destination information storage unit 10 Network 200 Management terminal

Claims (10)

A session information monitoring means that monitors the number of sessions for each of the plurality of modules that make up the application and outputs a deployment release request when the number of sessions of the first module that directly accepts the request becomes 0.
When the undeployment request is received, the first module is undeployed, and a module undeployment means for undeploying a module that is no longer called by any module is provided.
Information processing system. The information processing system according to claim 1, wherein the module undeployment means recursively undeploys a module that is no longer called by any module. When the number of sessions of the first module becomes 0, the session information monitoring means outputs a deployment release request including the module name and module version of the first module to the module deployment release means.
When the module undeployment means receives the undeployment request, it undeploys the module name and the module version of the first module included in the undeployment request, and is thereby called from any module. The information processing system according to claim 1 or 2, wherein a module having a module name and a module version that is no longer available is undeployed. The information processing system according to claim 3, wherein the session information monitoring means does not output the deployment release request when the module version of the first module in which the number of sessions has become 0 is the latest module version. .. The information processing system according to claim 3 or 4, wherein the module undeployment means does not undeploy the module when the module version of the module that is no longer called from any of the modules is the latest module version. Further equipped with session information management means
The session information management means notifies the session information monitoring means of the session ID of the session requested to be deleted or the session in which a predetermined time has elapsed from the last access time.
The information processing system according to any one of claims 3 to 5. Further equipped with a session distribution destination information storage means for storing the session table,
In the session table, the module name is associated with the session ID of the session for the module and the module version of the load module to be distributed.
The session information monitoring means determines whether or not the number of sessions of the first module has become 0 based on the notified session ID and the session table.
The information processing system according to claim 6. The information processing system is connected to the management terminal via a network and is connected to the management terminal.
Upon receiving the deployment release request of the first module from the management terminal,
The module undeployment means also has a function of undeploying the first module in response to a deployment undeployment request received from the management terminal, and also undeploying a module that is no longer called by any module.
The information processing system according to any one of claims 1 to 7. Monitor the number of sessions for each of the multiple modules that make up your application
When the number of sessions of the first module that directly accepts the request becomes 0, the first module is undeployed, and the module that is no longer called by any module is undeployed.
Information processing method. To the processor
Monitor the number of sessions for each of the multiple modules that make up your application
When the number of sessions of the first module that directly accepts the request becomes 0, the first module is undeployed, and the module that is no longer called by any module is undeployed.
A program that executes processing.

Images