KR20110064486A - System for controlling consistency of metadata cache in saas platform capable of providing multi-tenancy and method thereof - Google Patents

Abstract

PURPOSE: A consistency control system and method of a meta data cache in an SaaS platform supporting multi-tenancy are provided to reflect the change of meta data to the meta data cache of a corresponding web application by tracking of a corresponding web application server in the change of the meta data. CONSTITUTION: Web application servers(100~102) respectively include a meta data cache(110~112). In case the saved meta data of the meta data cache is changed, a database(120) traces a corresponding web application. The corresponding web application has the previous version meta data of change-requested meta data. The database transmits the changed meta data to the web application server. The database updates the meta data cache.

Description

SYSTEM FOR CONTROLLING CONSISTENCY OF METADATA CACHE IN SAAS PLATFORM CAPABLE OF PROVIDING MULTI-TENANCY AND METHOD THEREOF}

The present invention relates to a SaaS platform that supports multi-tenancy, and in particular, to improve performance in a SaaS platform that supports multi-tenancy through metadata stored in a database. Consistency of metadata caches on SaaS platforms that support multi-tenancy to ensure that the database and metadata cache data are consistent when metadata caches are placed on multiple web application servers. It relates to a control method.

The present invention is derived from a study conducted as part of the IT growth engine technology development project of the Ministry of Knowledge Economy [Task management number: 2009-S-033-01, Task name: Development of SaaS platform for SME SW service].

The SaaS platform that supports multi-tenancy supports tenant-specific customization of SaaS services, a web user interface for the user interface, and a workflow for service processing. (work flow) and data schema information for the data structure defined in the service are all stored and managed in the database in the form of metadata. It reads and interprets metadata from tenant users' service requests, executes the corresponding workflow, imports the necessary data, and passes the user web user interface (ie, web page).

To handle user requests, the SaaS platform needs to read metadata from the database each time over a network with small amounts and few updates. So by putting metadata in a web application cache, you can retrieve and process the necessary metadata from the cache without accessing the database over the network.

FIG. 1 illustrates a configuration of a conventional SaaS platform system. A SaaS platform system includes n web application servers 100, 101, and 102 and a database 120, and each web application server 100, 101, 102 includes metadata caches 110, 111, 112 to cache metadata in database 120.

As shown in FIG. 1, the conventional web application server 100, 101, 102 obtains metadata from the database 120 through a network whenever a user request is processed using the metadata cache 110, 111, 112. Metadata can be read and processed from the metadata caches 110, 111, and 112 provided in the web application servers 100, 101, and 102 without coming overhead.

However, in the conventional SaaS platform system including a web application server having a metadata cache and a database storing metadata, when the metadata in the database is changed as a result of customization by a tenant administrator (customization tool). There is a problem in that data inconsistency occurs between changed metadata of a database and metadata stored in a metadata cache provided in a web application server.

Accordingly, the present invention provides a method for controlling the consistency of a metadata cache in a SaaS platform supporting multi-tenancy, and implements a metadata cache trace list and a lease configuration data table for tracking and managing a metadata cache in a database. Of the metadata cache on the SaaS platform that supports multi-tenancy that keeps the metadata cache consistent by tracking the web application server when the change is made and reflecting the metadata changes in the metadata cache of the web application. We want to provide a consistency control method.

The present invention described above is a system for controlling consistency of a metadata cache in a SaaS platform supporting multi-tenancy, and includes a web application server including a metadata cache and a change in metadata stored in the metadata cache. And a database that tracks the web application having previous version metadata of the requested metadata and sends the modified metadata to the web application server to update the metadata cache.

The database may include a metadata cache server tracking list for tracking whether the web application server has updated the metadata.

The metadata cache server tracking list may include IP address information of the web application server, metadata version number information, and lease acquisition time information obtained from the metadata.

In addition, the database sets a lease validity time for ensuring that the metadata is valid for metadata provided to the web application server, and the web application server extends a lease for the metadata every time the lease validity time elapses. The metadata may be updated by request.

In addition, when receiving the update request for the metadata cache from the web application server, the database retrieves the metadata for the updated tenant identifier and service identifier and transmits the changed metadata to the web application server. Characterized in that.

The database may change the lease acquisition time of the metadata transmitted to the web application server to a time for transmitting the metadata to the web application server when the metadata is updated.

The database may further configure a new list entry for the tenant identifier and the service identifier when the metadata for the updated tenant identifier and the service identifier is not retrieved when the update request for the metadata cache is received. Characterized by generating and providing the metadata.

In addition, the database, when the metadata update request to the web application server fails, characterized in that for recording the log information of the failure of the metadata update request.

In addition, when the web application server receives the changed metadata from the database, the web application server searches for a list entry corresponding to the changed metadata in the metadata cache and stores the metadata stored in the metadata field in the list entry. And updating the changed metadata.

The web application server may receive the changed metadata, and update the lease acquisition time in the list entry to the time at which the metadata is updated when the metadata is updated.

The web application server may also have lease valid time information for metadata in list entries for each tenant in the metadata cache, and the metadata may be stored in the database for metadata of list entries for which the lease valid time expires. And updating the metadata cache by performing a lease extension request.

In addition, the web application server checks the last access time for the metadata stored in the list entry for each tenant in the metadata cache, and if the elapsed time from the last access time exceeds the preset timeout time, the corresponding metadata It is characterized in that to delete from the metadata cache.

In addition, the present invention provides a method for controlling the consistency of a metadata cache in a SaaS platform that supports multi-tenancy including a web application server and a database, the method comprising: providing lease-based metadata from the database to the web application server; Checking if a change to the metadata stored in the metadata cache of the web application server occurs in the database; and if the change occurs to the metadata, the web application having the changed metadata. Tracking a server, and updating the metadata cache by sending the changed metadata to the tracked web application server.

The method may further include changing, by the web application server, the lease acquisition time of the metadata to the time at which the metadata is received after the updating of the metadata cache.

In addition, when the lease valid time in the lease-based metadata expires, the web application server requests the database to extend the lease valid time of the corresponding metadata.

The present invention also provides a method for controlling the consistency of a metadata cache in a SaaS platform that supports a multi-tenancy including a web application server and a database, the method comprising: receiving an update request for a metadata cache from the web application server;

Reading a tenant identifier and a service identifier for the updated requested metadata from the database, and searching for metadata corresponding to the tenant identifier and a service identifier in the managed metadata cache server tracking list for each web application server; And transmitting the retrieved metadata to the web application server to update the metadata cache.

The metadata cache server tracking list may include IP address information of the web application server, metadata version number information, and lease acquisition time information obtained from the metadata.

The method may further include, after updating the metadata cache, changing the lease acquisition time of the metadata in the database to a time when the metadata is transmitted to the web application server.

The present invention also provides a method for controlling the consistency of a metadata cache in a SaaS platform that supports multi-tenancy including a web application server and a database, the method comprising: receiving an update request for the metadata cache of the web application server from an external source; Reading a tenant identifier and service identifier for the updated requested metadata from the database, and a corresponding web application IP address; and the tenant identifier and service identifier in the managed metadata cache server tracking list for each web application server. Retrieving the metadata corresponding to the and transmitting the retrieved metadata to a corresponding web application server corresponding to the IP address to update the metadata cache.

In addition, the present invention is a method of controlling the consistency of the metadata cache in a SaaS platform that supports multi-tenancy including a web application server and a database, the web application server to check the last access time for each metadata stored in the metadata cache Checking the elapsed time that elapsed from the last access time for each metadata to the current time; and deleting the corresponding metadata from the metadata cache when the elapsed time exceeds a preset predetermined tine out time. It includes.

In the present invention, as a method for controlling the consistency of the metadata cache in a SaaS platform supporting multi-tenancy, a metadata cache trace list and a lease configuration data table for tracking and managing a metadata cache in a database are implemented, and the metadata is changed. By tracking the web application server corresponding to the time, the metadata change is reflected in the metadata cache of the web application, thereby maintaining the consistency of the metadata cache.

In addition, when providing metadata from the database to the web application server, a lease indicating the validity period of the metadata is set so that after a predetermined lease period has elapsed, the database is requested to be reset to the lease period of the metadata. When performing a metadata update request, even if the metadata update request is not delivered due to the failure of the web application server, the metadata is taken when each web application server accesses the database to reset the lease period. There is an advantage to maintaining the consistency of the metadata cache by having to update.

In addition, the metadata stored in the metadata cache that is not used for a certain reference time is periodically checked and deleted by the web application server, thereby reducing the unnecessary occupied space of the metadata cache and increasing the efficiency of use. There is this.

Hereinafter, with reference to the accompanying drawings will be described in detail the operating principle of the present invention. In the following description of the present invention, if it is determined that a detailed description of a known function or configuration may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted. The following terms are defined in consideration of the functions of the present invention, and may be changed according to the intentions or customs of the user, the operator, and the like. Therefore, the definition should be based on the contents throughout this specification.

FIG. 2 illustrates a configuration of a SaaS platform system according to an exemplary embodiment of the present invention. The present invention includes a metadata cache server tracking table and a lease configuration data table on a database for maintaining consistency of the metadata cache.

Hereinafter, an operation of maintaining the consistency of the metadata caches 210, 211, and 212 between the web application servers 200, 201, and 202 and the database 220 in the SaaS platform system will be described in detail with reference to FIG. 2.

First, when an update of the metadata of the database 220 is requested by the tenant customization tool 203, the database 220 receiving the update request caches who and what metadata after updating the metadata. With reference to the metadata cache server trace list 230 that tracks and manages Hanji, a cache update request is sent to the web application server 200, 201, 202 to update the metadata.

On the other hand, when the database 220 sends a cache update request to the web application server (200, 201, 202), the web application server is interrupted by the administrator, CPU, board, power supply, network interface card (NIC) In some cases, a cache update request may not be received due to a problem such as a network cable or a switch error.

To this end, in the present invention, when the web application server 200, 201, 202 caches the metadata, a lease (the metadata cache is valid only for a predetermined time) is applied to each web application server 200, 201, The web application server (200, 201, 202) having a lease whose valid time has elapsed by issuing to 202 causes the lease to request a lease again, thereby solving the cache mismatch problem caused by various errors. Such lease setting information is stored and managed in the lease setting data table 240 in the database 220.

FIG. 3 illustrates a structure of a metadata cache according to an embodiment of the present invention. The metadata cache includes tenant and service units, and the entirety of the metadata cache is a list head 300. Beginning with the configuration, the list entries are formed in the form of list entries 310 and 320.

Each list entry 310, 320 includes a tenant identifier 311, 321, a service identifier 312, 322, version number 313, 323 of cached metadata, Lease time (314, 324), lease period (315, 325), last access time (316, 326) to access cache data, and actual The cache is composed of metadata 317 and 327.

4 illustrates a configuration of lease setting data according to an embodiment of the present invention.

The lease settings stored and managed in the database 220 are tenant identifiers 411, 421, and 431, service identifiers 412, 422, and 432, as shown in FIG. 4 above. Metadata version number (413, 413, 414), lease period (414, 424, 434).

That is, in the present invention, in order to cope with all kinds of failures of the web application server, the lease is used to maintain cache consistency. The lease indicates that the metadata cache is valid only for a certain time. The lease validity time is managed by tenant and service.

5 illustrates a configuration of a metadata cache tracking list according to an embodiment of the present invention.

Referring to FIG. 5, the metadata cache server trace list includes a tracking management entry 500 and a list head 503 composed of a tenant identifier 501 and a service identifier 502 to be tracked and managed. Doing. The list head 503 includes list entries 514, 524, and 534 of the web application server that cached the metadata.

Each list entry 514, 524, 534 is a version number (511, 521, 531) of the cached metadata, the lease time (512, 522, 532), and the web application It consists of IP (Internet Protocol) addresses 513, 523, 533 of a web application server.

As described above, the configured metadata cache server tracking list diagram is used when the database 220 determines which web application server to send an update request to when updating metadata. For web application servers that do not receive an update request due to an error, they wait for the maximum lease validity time and then request a lease update of the cached metadata and receive the updated metadata again to maintain consistency.

6 is a flowchart illustrating an operation control process of processing metadata in a web application server according to an exemplary embodiment of the present invention. Hereinafter, embodiments of the present invention will be described in detail with reference to FIGS. 2, 3, and 6.

First, a user belonging to a tenant requests a service to the web application server 200 (S600). Then, the web application server 200 obtains a tenant ID of the user who requested the service and a service ID of the requested service (S602).

Subsequently, the web application server 200 reads the list head 300 from the metadata cache 210 (S604), and then sequentially starts the list head 310 from the metadata cache 210 starting with the list head 300. , 320, and check whether the tenant identifier / service identifier of the list entries 310 and 320 is the same as the tenant identifier / service identifier of the user who requested the service (S620).

In this case, when the tenant identifier / service identifier of the list entries 310 and 320 is not the same as the tenant identifier / service identifier of the user who requested the service, the web application server 200 obtains the next list entry from the metadata cache 210 (S610). ).

The web application server 200 checks whether the tenant identifier / service identifier of the second-listed list entry is the same as the tenant identifier / service identifier of the user who requested the service (S620). In this manner, the web application server 200 performs a check on all list entries 310 and 320 included in the metadata cache 210 (S610, S620, and S622).

In this case, if the tenant identifier / service identifier of the list entries 310 and 320 is the same as the tenant identifier / service identifier of the user who requested the service, the tenant identifier and service identifier of the user who requested the service are retrieved from the metadata cache 210. Means that.

Accordingly, the web application server 200 reads the lease acquisition time (314, 324) and the lease valid time (lease period) (315, 325) from the list entry corresponding to the retrieved tenant identifier and service identifier. In operation S630, the user checks whether the current time of requesting the service is smaller than the reference time that adds the lease acquisition time 314 and 324 and the lease valid time 315 and 325.

At this time, when the current time is smaller than the reference time, the web application server 200 imports the metadata 317 and 327 included in the corresponding list entry 310 or 320 (S646), and within the list entries 310 and 320. The last access time field is updated to the current time (S648). Subsequently, the web application server 200 processes the user service by interpreting the metadata (S650).

Alternatively, however, if the current time is greater than the reference time, this means that the lease validity time for the metadata of the corresponding list entry 310, 320 has expired, so that the web application server 200 services the database 220. A new lease is requested with the tenant identifier, service identifier, and version number of the requested user (S632).

At this time, if the lease request is successful because there is no change of metadata for the corresponding tenant identifier and the service identifier in the database 220 (S640), the web application server 200 enters the corresponding list entry in the metadata cache 210. When the lease acquisition time of the 310 and 320 is updated (S644), and the lease request fails due to metadata change of the corresponding tenant identifier and the service identifier (S640), the web application server 200 ) Obtains the lease valid time and the changed metadata for the tenant identifier and the service identifier (S642).

Meanwhile, after reading the list head 300 from the metadata cache 210 in step S610, the list entries 310 and 320 are sequentially taken from the metadata cache 210 starting with the list head 300. The tenant identifier / service identifier of the list entries 310 and 320 is equal to the tenant identifier / service identifier of the user who requested the service until the last list entry, and the tenant identifier / service of the user who requested the service in the metadata cache 210 is checked. If there is no list entry that matches the identifier, the web application server 200 generates a new list entry (S612).

Subsequently, the web application server 200 sets a tenant identifier and a service identifier of the user in the list entry generated as described above (S614), adds the list entry to the list head 300, and verifies the version number of the list entry (version number). ) Is set to '0' (S618). In this way, as the version number is set to '0', it is recognized as a new tenant identifier and a service identifier from the database 220.

7 illustrates an operation control flow for processing a lease request in a database according to an embodiment of the present invention. Hereinafter, embodiments of the present invention will be described in detail with reference to FIGS. 2, 3, 5, and 7.

First, when receiving a lease request from the web application server 200 (S700), the database 220 obtains an IP address of the web application server 200 requesting a lease (S702), and a tenant identifier (sent) transmitted according to the lease request (S700). A tenant ID), a service ID, and a version number are obtained (S704).

Subsequently, the database 220 reads the metadata cache server trace list 230 to process the request (S706), and then sequentially lists the metadata cache server trace list 230 starting from the list head 503. Take the entries 514, 524, 534 (S708) to see if the tenant ID / service ID of the list entry 514, 524, 534 is the same as the tenant identifier / service identifier requested for service. Inspect (S720).

At this time, if the tenant identifier / service identifier of the list entries 514, 524, and 534 is not the same as the tenant identifier / service identifier requested for the service, the database 220 obtains the next list entry from the metadata cache server trace list 230. (S710).

Then, the database 220 checks again whether the tenant identifier / service identifier of the second-listed list entry is the same as the tenant identifier / service identifier requested for service (S720). In this way, the database 220 performs a check on all list entries 514, 524, and 534 included in the metadata cache server trace list 230 (S710, S720, and S722).

In this case, if the tenant identifier / service identifier of the list entries 514, 524, and 534 becomes the same as the service-required tenant identifier / service identifier, the service-required tenant identifier and the service identifier are the metadata cache server trace list 230. It means that it is colored.

Accordingly, the database 220 checks whether the version number (511, 521, 531) recorded in the version number field of the retrieved list entry and the version number received in the lease request are the same (S730).

In this case, when the version number is the same, this means that the metadata corresponding to the lease requested tenant identifier and the service identifier has not changed, and the database 220 sets the lease request result value to success (S732), and the searched list. The lease acquisition time (512, 522, 532) of the entry is updated to the current time (S740).

Subsequently, the database 220 transmits the result value and the version number of the lease request to the web application server 200 requesting the service (S742), and when there is a lease valid time value and metadata to be transmitted to the web application server 200. This is transmitted to (S744).

However, in contrast, when the version number received in the lease request and the version number recorded in the version number field of the retrieved list entry are different, this means that the metadata corresponding to the lease requested tenant identifier and the service identifier are upgraded and changed. Therefore, the database 220 sets the lease request result value as failure (S734), obtains the changed metadata cache for the service-required tenant identifier and the service identifier, and provides it to the web application server 200 (S736). .

On the other hand, after reading the list head 503 from the metadata cache server trace list 230 in step (S710), the list entry (from the metadata cache server trace list 230 starting with the list head 503) 514, 524, 534 is retrieved and the metadata cache server trace is checked until the last list entry to see if the tenant identifier / service identifier in list entry 514, 524, 534 is the same as the tenant identifier / service identifier requested for service. If there is no list entry that matches the service requested tenant identifier / service identifier in the list 230, the database 220 generates a new list entry in the metadata cache server trace list 230 (S712).

Subsequently, the database 220 sets the tenant identifier, the service identifier, and the IP address of the web application server to which the service is requested in the list entry generated as described above (S714).

Thereafter, the database 220 sets a version number and a lease valid time value (S716), and adds the list entry to the list head 503 of the metadata cache server trace list 230 (S718).

8 illustrates an operation control flow for updating metadata in response to a metadata update request from a tenant manager in a database according to an embodiment of the present invention. Hereinafter, embodiments of the present invention will be described in detail with reference to FIGS. 2, 3, 5, and 8.

First, when receiving a metadata update request from the tenant manager 203 (S800), the database 220 obtains a tenant ID and a service ID (S802).

Subsequently, the database 220 changes the metadata corresponding to the tenant identifier and the service identifier and increments the version number value of the corresponding metadata of the lease setting data table 240 by 1 (S804). In addition, the database 220 searches the metadata cache server trace list 230 to obtain a tracking management entry 500 for the tenant identifier and the service identifier (S806).

Subsequently, the list head 503 of the tracking management entry 500 is taken (S808) to check whether the current time is smaller than the reference time value obtained by adding the lease acquisition time and the lease valid time of the list head 503 (S810).

At this time, if the current time is less than the reference time, it means that the lease valid time for the metadata of the corresponding list entry 514, 524, 534 has not yet expired, and thus the web application of the corresponding list entry 514, 524, 534. Do not send metadata update requests to the server.

However, in contrast, if the current time is greater than the reference time, it means that the lease expiration date for the metadata of the corresponding list entry has expired, and thus the database 220 sends a metadata update request to the web application server of the corresponding list entry. It is to be transmitted (S812).

In this case, the web application server may not receive the metadata update request due to an interruption caused by an administrator, a CPU, a board, a power supply, a network interface card (NIC), a network cable, a switch error, or the like.

As described above, when the metadata update request to the web application server fails (S814), the database 220 stores a log of the update request failure (S816).

9 illustrates an operation control flow for processing metadata update in a web application server according to an embodiment of the present invention. Hereinafter, embodiments of the present invention will be described in detail with reference to FIGS. 2, 3, and 9.

First, when receiving a metadata update request from the database 220 (S900), the web application server 200 obtains a tenant ID and a service ID from the update request (S902).

Subsequently, the web application server 200 reads the list head 300 from the metadata cache 210 (S904), and then sequentially starts the list entry 310 from the metadata cache 210 starting with the list head 300. In operation S920, it is checked whether the tenant identifier / service identifier of the list entry 300 is the same as the tenant identifier / service identifier requested to be updated.

At this time, when the tenant identifier / service identifier of the list entries 310 and 320 is not the same as the tenant identifier / service identifier requested to be updated, the web application server 200 obtains the next list entry from the metadata cache 210 (S924). .

Then, the web application server 200 checks whether the tenant identifier / service identifier of the second-listed list entry is the same as the tenant identifier / service identifier requested to be updated (S920). In this way, the web application server 200 checks all list entries included in the metadata cache 210 (S910, S920, S922).

In this case, if the tenant identifier / service identifier of the list entries 310 and 320 is equal to the tenant identifier / service identifier requested to be updated, this means that the tenant identifier / service identifier requested to be updated is retrieved from the metadata cache.

Accordingly, the web application server 200 subtracts the lease acquisition time (314, 324) of the retrieved list entries (310, 320) from the present time lease period (315, 325) The update is set to time (S922). In other words, the lease validity time of the update-requested metadata is changed so that the changed metadata cache is received again.

FIG. 10 illustrates an operation control flow for removing an unused cache from among metadata caches in a web application server according to an embodiment of the present invention. Hereinafter, embodiments of the present invention will be described in detail with reference to FIGS. 2, 3, and 10.

First, the web application server 200 obtains an execution cycle value (S1000) and a timeout setting value (S1002).

Subsequently, the web application server 200 checks whether the operation of the server is stopped (S1010). If the operation of the server is not stopped, the web application server 200 obtains the list head from the metadata cache 210 (S1012), and then the list head ( Starting with 300, the list entries 310 and 320 are sequentially obtained from the metadata cache 210 (S102), and the last access time (last access time) when the metadata in the list entries 310 and 320 is accessed. 316 and 326 check whether the current time is smaller than the reference time obtained by subtracting the timeout setting time (S1030).

At this time, when the last access time (316, 326) of the list entry is greater than the reference time, the web application server 200 obtains the next list entry from the metadata cache 210 (S1036).

Then, the web application server 200 checks again whether the last access time of the second list entry is smaller than the reference time (S1030). In this manner, the web application server 200 checks the last access time for all list entries included in the metadata cache 210 (S1020, S1030, and S1036).

In this case, if the last access time of the list entry is less than the reference time, this means that the metadata in the list entry has not been used so that the timeout set after the last access time has elapsed. The list entry is removed from the metadata cache 210 to prevent unnecessary space occupancy of the metadata cache 210 (S1032).

Meanwhile, when the final access time is checked for all list entries in the metadata cache 210 in step S1010, the web application server 200 sleeps for a predetermined predetermined execution period, and then again stores the metadata cache. In operation 210, an unused cache is removed.

As described above, the present invention provides a method for controlling the consistency of a metadata cache in a SaaS platform supporting multi-tenancy, and implements a metadata cache server trace list and a lease configuration data table for tracking and managing a metadata cache in a database. When the metadata is changed, the corresponding web application server is tracked so that the metadata change is reflected in the metadata cache of the web application to maintain the consistency of the metadata cache.

Also, when providing metadata from a database to a web application server, a lease indicating the validity period of the metadata is set so that after a certain lease period has elapsed, the database is requested to reset the lease period of the metadata. When performing a metadata update request to the server, even if the metadata update request is not delivered due to the interruption of the web application server, the metadata is changed when each web application server accesses the database to reset the lease period. By updating the data, you ensure that the metadata cache is consistent.

While the invention has been shown and described with reference to certain preferred embodiments thereof, it will be understood by those skilled in the art that various changes and modifications may be made without departing from the spirit and scope of the invention. Accordingly, the scope of the invention should not be limited by the described embodiments but should be defined by the appended claims.

1 is a configuration diagram of a conventional SaaS platform,

2 is a configuration diagram of a SaaS platform supporting multi-tenancy according to an embodiment of the present invention;

3 is a cache configuration diagram of a web application server according to an embodiment of the present invention;

4 is a configuration diagram of the lease setting data according to an embodiment of the present invention;

5 is a block diagram of a metadata cache server tracking list according to an embodiment of the present invention;

6 is a flowchart illustrating metadata processing in a web application server according to an embodiment of the present invention;

7 is a flowchart illustrating a lease request processing in a database according to an embodiment of the present invention;

8 is an operation control flowchart of processing a metadata update request in a database according to an embodiment of the present invention;

9 is an operation control flowchart for processing metadata update in a web application server according to an embodiment of the present invention;

FIG. 10 is a flowchart illustrating an operation control for removing an unused cache among metadata caches in a web application server according to an exemplary embodiment of the present invention. FIG.

<Brief description of the major symbols in the drawings>

200: web application server 220: database

203: Tenant Manager 230: Metadata Cache Server Trace List

240: lease setting data table

Claims (20)

As a consistency control system of metadata cache in multi-tenancy SaaS platform, A web application server having a metadata cache, If there is a change in metadata stored in the metadata cache, the web application having the previous version metadata of the change requested metadata is tracked, and the changed metadata is transmitted to the web application server to transmit the metadata. Database to update data cache Consistency control system of metadata cache in a SaaS platform that supports multi-tenancy including a. The method of claim 1, The database, Consistency control system of metadata cache in a SaaS platform that supports multi-tenancy with a metadata cache server tracking list for tracking whether the web application server metadata update. The method of claim 2, The metadata cache server tracking list is Consistency control system of the metadata cache in a SaaS platform that supports multi-tenancy including the IP address information of the web application server, metadata version number information and lease acquisition time information obtained from the metadata. The method of claim 1, The database, Set a lease validity time that guarantees that the metadata is valid for metadata provided to the web application server, and the web application server requests a lease extension for the metadata every time the lease validity time elapses. Consistency Control System of Metadata Cache on SaaS Platforms that Support Multi-Tenancy for Performing Updates. The method of claim 1, The database, When receiving an update request for the metadata cache from the web application server, a multi-tenancy that retrieves metadata for the updated tenant identifier and service identifier and transmits changed metadata to the web application server. Consistency Control System of Metadata Cache on Supported SaaS Platforms. The method of claim 5, The database, Consistency of the metadata cache in the SaaS platform that supports multi-tenancy to change the lease acquisition time of the metadata transmitted to the web application server to the time to transmit the metadata to the web application server when updating the metadata. Control system. The method of claim 5, The database, When receiving the update request for the metadata cache, if the metadata for the updated tenant identifier and the service identifier is not retrieved, a new list entry is formed for the tenant identifier and the service identifier, and the metadata is generated and provided. Consistency Control System of Metadata Cache in SaaS Platforms Supporting Multitenancy. The method of claim 5, The database, The metadata cache consistency control system of the SaaS platform that supports multi-tenancy to record log information of the failure of the metadata update request when the metadata update request to the web application server fails. The method of claim 1, The web application server, When the changed metadata is received from the database, the multi-tenant retrieves a list entry corresponding to the changed metadata from the metadata cache and updates the metadata stored in the metadata field in the list entry with the changed metadata. Consistency Control System of Metadata Cache on SaaS Platforms that Support City. The method of claim 9, The web application server, Consistency control of the metadata cache in the SaaS platform that supports the multi-tenancy that receives the changed metadata and updates the lease acquisition time in the list entry to the time when the metadata is updated when the metadata is updated. system. The method of claim 1, The web application server, The lease valid time information of the metadata in the list entry for each tenant in the metadata cache is provided, and for the metadata of the list entry for which the lease valid time expires, a lease extension request for the metadata is made to the database. Consistency control system of the metadata cache in the SaaS platform that supports multi-tenancy to perform the update of the metadata cache. The method of claim 1, The web application server, Examining the last access time for the metadata stored in the list entry for each tenant in the metadata cache and deleting the corresponding metadata from the metadata cache when the elapsed time from the last access time exceeds the preset timeout time. Consistency Control System of Metadata Cache on SaaS Platforms Supporting Multi-Tenancy. As a method of controlling the consistency of metadata cache in the SaaS platform that supports multi-tenancy including web application server and database, Providing lease-based metadata from the database to the web application server; Checking in the database if a change occurs in the metadata stored in the metadata cache of the web application server; Tracking the web application server having the metadata in which the change occurred, when a change to the metadata occurs; Transmitting the changed metadata to the tracked web application server to update the metadata cache. How to control the consistency of the metadata cache in a SaaS platform that supports multi-tenancy, including. The method of claim 13, After updating the metadata cache, changing the lease acquisition time of the metadata to the time at which the metadata is received by the web application server. How to control consistency. The method of claim 13, The web application server, How to control the consistency of the metadata cache in the SaaS platform that supports multi-tenancy to request the lease valid time extension of the metadata to the database when the lease valid time in the lease-based metadata expires. As a method of controlling the consistency of metadata cache in the SaaS platform that supports multi-tenancy including web application server and database, Receiving an update request for a metadata cache from the web application server; Reading a tenant identifier and a service identifier for the update requested metadata from the database; Retrieving metadata corresponding to the tenant identifier and a service identifier from the managed metadata cache server tracking list for each web application server; Transmitting the retrieved metadata to the web application server to update the metadata cache. How to control the consistency of the metadata cache in a SaaS platform that supports multi-tenancy, including. The method of claim 16, The metadata cache server tracking list is The method of controlling the consistency of the metadata cache in the SaaS platform that supports multi-tenancy including the IP address information of the web application server, metadata version number information and lease acquisition time information obtained from the metadata. The method of claim 16, And after updating the metadata cache, changing the lease acquisition time of the metadata in the database to the time when the metadata is transmitted to the web application server. To control the consistency of the metadata cache in the database. As a method of controlling the consistency of metadata cache in the SaaS platform that supports multi-tenancy including web application server and database, Receiving an update request for a metadata cache of the web application server from the outside; Reading a tenant identifier, a service identifier, and a corresponding web application IP address for the updated requested metadata from the database; Retrieving metadata corresponding to the tenant identifier and the service identifier from the managed metadata cache server tracking list for each web application server; Transmitting the retrieved metadata to the corresponding web application server corresponding to the IP address to update the metadata cache. How to control the consistency of the metadata cache in a SaaS platform that supports multi-tenancy, including. As a method of controlling the consistency of metadata cache in the SaaS platform that supports multi-tenancy including web application server and database, Checking a final access time for each metadata stored in a metadata cache at the web application server; Checking an elapsed time that elapses from the last access time for each metadata to a current time; Deleting the corresponding metadata from the metadata cache when the elapsed time exceeds a predetermined predetermined tine out time. How to control the consistency of the metadata cache in a SaaS platform that supports multi-tenancy, including.

Images