Use method of database shared object and related product

By using two mechanisms that reference bitmap, state variable and version variable in the database system, the shared objects are cached to the process local, solving the communication bottleneck caused by the lock mechanism and improving the operating efficiency and concurrency of the database system.

CN120407227APending Publication Date: 2025-08-01CETC JINCANG (BEIJING) TECH CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202510428853.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-04-07
Publication Date
2025-08-01

AI Technical Summary

Technical Problem

In a multi-process architecture database system, frequent shared variable reading operations lead to a lock mechanism forming a system communication bottleneck, affecting the operation efficiency of the database system.

Method used

Two mechanisms referring to bitmap, state variable and version variable are adopted to cache shared objects to the process locally, reducing frequent acquisition of locks and improving access speed and efficiency.

Benefits of technology

Accelerate the process's access speed to shared objects, reduce the risk of communication bottlenecks, improve the operation efficiency of the database system, and prevent concurrent errors.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120407227A_ABST
    Figure CN120407227A_ABST
Patent Text Reader

Abstract

The invention provides a use method of a database shared object and a related product. The use method comprises the following steps: creating two reference bitmaps corresponding to a shared object; under the condition that any process serves as a cache process to cache the shared object locally, one of the mark slots of the corresponding cache processes of the two reference bitmaps is selectively set as a cache mark according to a state variable of the shared object; the version variables of the two reference bitmaps are cached locally in the caching process; and under the condition that any process is used as a release process to release the shared object, one of the mark slots of the corresponding release processes of the two reference bitmaps is selectively set as a release mark according to the state variable, the version variable and the version variable of the release process. Under the condition of not generating a concurrent error problem, the access speed of the process to the shared object is accelerated, the efficiency of using the shared object by the process is improved, the communication bottleneck risk of the database system is reduced, and the operation efficiency of the database system is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the technical field of databases, and in particular to a method for using a database shared object, a computer-readable storage medium, a computer program product, and a computer device. Background Art

[0002] In a database system with a multi-process architecture, each process has an independent address space, and each process can usually only read and write variables in its own stack. The database system usually sets variables that can be shared by all processes (referred to as shared memory variables or shared variables). Shared variables usually use the shared memory of the database system so that they can be obtained or changed by each process. Since the shared variables are globally shared, when process A changes a shared variable, if process B reads the shared variable after process A has completed the change, then process B can read the changed value. If process B reads the shared variable before process A has completed the change, then process B may not read the result it expects to read, and may cause concurrent error problems.

[0003] To solve the above problems, a lock mechanism is usually set for shared variables in the related art. Specifically, when any process needs to read the shared variable, it always first obtains a shared mode lock (also called a shared lock) that locks the shared variable. When any process needs to change the shared variable, it always first obtains an exclusive mode lock (also called an exclusive lock) that locks the shared variable.

[0004] However, when each process in the database system frequently reads a certain shared variable, it is necessary to frequently obtain shared locks, which easily forms a system communication bottleneck, and further affects the operation efficiency of the database system. Summary of the Invention

[0005] An object of the present invention is to provide a method for using a database shared object, a computer-readable storage medium, a computer program product, and a computer device to improve the efficiency of each process in the database using the shared object, thereby improving the operation efficiency of the database system.

[0006] Specifically, according to one aspect of the present invention, the present invention provides a method for using a database shared object, including:

[0007] Create two reference bitmaps corresponding to the shared object, and each process in the database is mapped with an independent marker slot in the two reference bitmaps;

[0008] In the case where any of the processes caches the shared object locally as a caching process, according to the status variable of the shared object, one of the marker slots corresponding to the caching process in the two reference bitmaps is alternatively set to a cache marker, and the status variable reflects whether the shared object is being updated; and

[0009] The caching process caches the version variables of the two reference bitmaps locally, and the version variables reflect the current versions of the two reference bitmaps;

[0010] In the case where any of the processes releases the shared object as a releasing process, according to the status variable, the version variable, and the version variable of the releasing process, one of the marker slots corresponding to the releasing process in the two reference bitmaps is alternatively set to a release marker.

[0011] Optionally, the step of alternatively setting one of the marker slots corresponding to the caching process in the two reference bitmaps to a cache marker according to the status variable of the shared object includes:

[0012] The caching process determines whether the status variable is in an updated state;

[0013] If it is in a non-updated state, the marker slot corresponding to the caching process in the first reference bitmap among the two reference bitmaps is set to the cache marker;

[0014] If it is in the updated state, the marker slot corresponding to the caching process in the second reference bitmap among the two reference bitmaps is set to the cache marker.

[0015] Optionally, the step of alternatively setting one of the marker slots corresponding to the releasing process in the two reference bitmaps to a release marker according to the status variable, the version variable, and the version variable of the releasing process includes:

[0016] The releasing process determines whether the version variable and the version variable of the releasing process are consistent;

[0017] If they are inconsistent, the marker slot corresponding to the releasing process in the first reference bitmap is set to the release marker;

[0018] If they are consistent, the releasing process determines whether the status variable is in the updated state;

[0019] If it is in the non-updated state, the marker slot corresponding to the releasing process in the first reference bitmap is set to the release marker;

[0020] If it is the update state, set the flag slot corresponding to the release process in the second reference bitmap to the release flag.

[0021] Optionally, the update process of the shared object includes:

[0022] In response to any one of the processes triggering the condition for updating the shared object as an update process, the update process modifies the shared object;

[0023] The update process issues a broadcast requesting all other processes to modify their respective shared objects;

[0024] The update process sets the status variable to the update state;

[0025] In response to all the flag slots in the first reference bitmap being set to the release flag, the update process sets the status variable to the non-update state;

[0026] Exchange the values of all the corresponding flag slots in the first reference bitmap and the second reference bitmap;

[0027] Increment the version variable by one.

[0028] Optionally, the step for any one of the processes receiving the broadcast to modify its shared object includes:

[0029] Invalidate the shared object cached locally;

[0030] Cache the shared object modified by the update process locally.

[0031] Optionally, before the update process modifies the shared object, it further includes:

[0032] The update process acquires an exclusive lock on the shared object; and

[0033] After the update process issues a broadcast requesting all other processes to modify their respective shared objects, it further includes:

[0034] The update process releases the exclusive lock on the shared object.

[0035] Optionally, before the update process sets the status variable to the update state, it further includes:

[0036] The update process acquires an exclusive lock on the status variable and the version variable; and

[0037] After the update process sets the status variable to the update state, it further includes:

[0038] The update process releases the exclusive locks of the status variable and the version variable.

[0039] Optionally, before the update process sets the status variable to the non-updated state, it further includes:

[0040] The update process acquires the exclusive locks of the status variable and the version variable; and

[0041] After incrementing the version variable, it further includes:

[0042] The update process releases the exclusive locks of the status variable and the version variable.

[0043] Optionally, before the release process determines whether the version variable is consistent with the version variable of the release process, it further includes:

[0044] The release process acquires the shared locks of the status variable and the version variable; and

[0045] After setting the marked slot corresponding to the release process of the first reference bitmap or the second reference bitmap to the release mark, it further includes:

[0046] The release process releases the shared locks of the status variable and the version variable.

[0047] Optionally, before the caching process determines whether the status variable is in the updated state, it further includes:

[0048] The caching process acquires the shared locks of the status variable and the version variable; and

[0049] After the caching process caches the version variables of the two reference bitmaps locally, it further includes:

[0050] The caching process releases the shared locks of the status variable and the version variable.

[0051] Optionally, the step of the caching process caching the shared object locally includes:

[0052] Acquire the shared lock of the shared object;

[0053] Acquire the shared object;

[0054] Cache the shared object locally;

[0055] Release the shared lock of the shared object.

[0056] Optionally, the step of the release process releasing its shared object includes:

[0057] In response to the release process triggering an instruction to log off this process, or receiving a notice to modify its said shared object, it is determined whether there is the said shared object cached locally by the release process;

[0058] If so, release the said shared object cached locally.

[0059] According to another aspect of the present invention, there is also provided a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the usage method of the database shared object in any of the above are implemented.

[0060] According to still another aspect of the present invention, there is also provided a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the usage method of the database shared object in any of the above are implemented.

[0061] According to yet another aspect of the present invention, there is also provided a computer device, including a memory, a processor, and a computer program stored on the memory, and the processor executes the computer program to implement the steps of the usage method of the database shared object in any of the above.

[0062] The usage method of the database shared object of the present invention can accelerate the access speed of the process to the shared object by caching the shared object locally in the process, improve the efficiency of the process using the shared object, reduce the risk of communication bottlenecks in the database system, and improve the operating efficiency of the database system. By setting two reference bitmaps, a status variable, and a version variable for the shared object, it is convenient to determine whether all the shared objects before modification in all processes in this cycle have been released according to the values of the two reference bitmaps, thereby preventing concurrent error problems.

[0063] Those skilled in the art will become more apparent about the above and other purposes, advantages, and features of the present invention according to the following detailed description of the specific embodiments of the present invention in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0064] Some specific embodiments of the present invention will be described in detail hereinafter with reference to the accompanying drawings in an exemplary but non-limiting manner. The same reference numerals in the drawings denote the same or similar components or parts. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings:

[0065] Figure 1 is a flowchart of the usage method according to an embodiment of the present invention;

[0066] Figure 2 is a flowchart of caching and marking the reference bitmap for the usage method according to an embodiment of the present invention;

[0067] Figure 3 It is a schematic flowchart of releasing and marking a reference bitmap according to the usage method of an embodiment of the present invention;

[0068] Figure 4 It is a schematic flowchart of updating a shared object according to the usage method of an embodiment of the present invention;

[0069] Figure 5 It is a schematic flowchart of a process caching a shared object locally according to the usage method of an embodiment of the present invention;

[0070] Figure 6 It is a schematic flowchart of a process releasing its shared object according to the usage method of an embodiment of the present invention;

[0071] Figure 7 It is a schematic flowchart of a process modifying its shared object according to the usage method of an embodiment of the present invention;

[0072] Figure 8 It is a schematic diagram of a computer program product according to an embodiment of the present invention;

[0073] Figure 9 It is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and

[0074] Figure 10 It is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed implementation manners

[0075] The purpose of the usage method of the database shared object in this embodiment is to improve the efficiency of each process in the database using the shared object, thereby improving the operating efficiency of the database system.

[0076] Figure 1 It is a schematic flowchart of the usage method according to an embodiment of the present invention, and the method generally may include:

[0077] S100, creating two reference bitmaps corresponding to the shared object, and each process in the database is mapped with an independent marking slot in the two reference bitmaps;

[0078] S200, when any process caches the shared object locally as a caching process, alternatively setting one of the marking slots corresponding to the caching process in the two reference bitmaps as a cache mark according to the status variable of the shared object, where the status variable reflects whether the shared object is being updated; and

[0079] S300, the caching process caches the version variables of the two reference bitmaps locally, where the version variables reflect the current versions of the two reference bitmaps;

[0080]

[0080] In the case where the S400 releases a shared object in any process as a release process, one of the flag slots corresponding to the release process of the two reference bitmaps is alternatively set to a release flag according to the status variable, the version variable, and the version variable of the release process.

[0081]

[0081] Related technologies usually set a lock mechanism for shared objects (such as shared variables). When any process needs to read the shared object, it always first obtains a shared lock that locks the shared object. When any process needs to modify the shared object, it always first obtains an exclusive lock that locks the shared object. In practice, the update frequency of some shared objects is relatively low. For these shared objects, all processes may frequently perform read operations and rarely perform modification operations. This results in all processes frequently communicating with the node that has the control right of the lock of the shared object to request to obtain the shared lock of the shared object, thus easily forming a system communication bottleneck, and further affecting the operation efficiency of the database system.

[0082]

[0082] In this embodiment, when any process first uses a certain shared object, it caches it locally in the process (which can be called the caching process). Specifically, when the caching process first obtains the shared object, it needs to use a shared lock to obtain the shared object in the shared memory. After successfully obtaining it, it writes the value of the shared object to a certain position in its own address space. In this way, when the caching process performs subsequent read operations, it can obtain the value of the shared object by directly accessing the local shared object. When the process does not need to use the shared object (such as logging off the process, receiving relevant instructions, etc.), it needs to release the shared object cached locally (which can be called the release process). This solution can avoid frequently requesting the lock of the shared object and improve the operation efficiency of the database system.

[0083]

[0083] When using the above solution, the following problem will be faced: If a certain process modifies the shared object in the shared memory (which can be called the update process), that is, the update process modifies the value of the shared object, it will cause the value of the shared object in the shared memory to be inconsistent with the values of those shared objects that have been cached locally. That is to say, the shared object in the shared memory is the new version, while the shared object that has existed locally in the process before is the old version. If the caching process still uses the old version of the shared object, it may cause concurrent error problems, and further lead to serious consequences.

[0084]

[0084] To solve this problem, this embodiment further sets two reference bitmaps, a status variable, and a version variable for the two reference bitmaps for the shared object.

[0085] Each reference bitmap constructs a bitmap with a specific length to mark whether each process in the database caches the shared object locally. Exemplarily, when initializing the shared object in the shared memory, the first reference bitmap and the second reference bitmap can be generated together. Each process in the database corresponds to a unique marked slot in the first reference bitmap and the second reference bitmap, and each process can only operate on the marked slots belonging to this process in the first reference bitmap and the second reference bitmap, and cannot operate on the marked slots of other processes. The marked slots can include a cache mark (e.g., represented by 1) and a release mark (e.g., represented by 0). The initial state of each marked slot in the reference bitmap can be the release mark.

[0086] The status variable is used to reflect whether the shared object is being updated. Specifically, the status variable can include an updated state and a non-updated state. The initial state of the status variable can be the non-updated state. The status variable can be modified by any update process in the database. The update process of the shared object is a periodic process. For this round of the cycle, first, the update process modifies the shared object in the memory, and then notifies all other processes to release their shared objects (the shared objects cached locally in the previous round). After all releases are completed, the update process of the shared object in this round can end, waiting for the update process in the next round of the cycle. The status variable is used to reflect that the shared object in the shared memory has been modified in this round of the cycle. Exemplarily, when the update process completes the modification of the shared object in the shared memory in this round of the cycle, the status variable can be set to the updated state. When all processes release their shared objects in this round of the cycle, the status variable can be set to the non-updated state.

[0087] The version variable reflects the current versions of the two reference bitmaps. The value of the version variable can be a unique value. Exemplarily, the version variable can be an equal increment number (e.g., cumulative count). Each time the shared object is updated, the version variable needs to be incremented equally. After the caching process caches the shared object in the shared memory locally and sets the marked slot in the corresponding reference bitmap to the cache mark, it needs to cache the version variables of the two reference bitmaps locally to reflect the current versions of the two reference bitmaps to which the cache mark belongs. The version variable can be modified by any update process in the database.

[0088] In this embodiment, when the caching process caches a shared object locally, it obtains the value of the status variable, determines one of the first reference bitmap and the second reference bitmap according to the value of the status variable, and sets the marking slot corresponding to the caching process in it as the cache mark. For example, when the value of the status variable is the update state, the marking slot of the second reference bitmap can be set as the cache mark; when the value of the status variable is the non-update state, the marking slot of the first reference bitmap can be set as the cache mark. Since the value of the status variable can reflect whether the shared object in the shared memory has been modified in this round of cycle, therefore, by the value of the marking slot of the caching process in the first reference bitmap and the second reference bitmap, it can be conveniently determined whether the shared object cached by the caching process is before or after modification in this round of cycle.

[0089] In this embodiment, when the releasing process releases its shared object, it obtains the values of the status variable and the version variable in the shared memory, and obtains the value of the local version variable, and determines whether the shared object of the releasing process is from the previous round of cycle or this round of cycle according to these three values; if it is from this round of cycle, it can further determine whether it is before or after modification of the shared object in the shared memory in this round of cycle, and then determine whether the cache mark corresponding to the releasing process is in the first reference bitmap or the second reference bitmap, and then set it as the release mark. Exemplarily, when all the marking slots of the first reference bitmap are release marks, it indicates that all the shared objects before modification in all processes in this round of cycle have been released, and there is no concurrent error problem for the shared object in this round of cycle.

[0090] The method for using the database shared object in this embodiment can accelerate the access speed of the process to the shared object, improve the efficiency of the process using the shared object, reduce the risk of communication bottleneck in the database system, and improve the running efficiency of the database system by caching the shared object to the local of the process. By setting two reference bitmaps, a status variable and a version variable for the shared object, it can be conveniently determined whether all the shared objects before modification in all processes in this round of cycle have been released according to the values of the two reference bitmaps, thereby preventing the occurrence of concurrent error problems.

[0091] In some embodiments of the usage method of the present invention, as Figure 2 shown, the step of alternatively setting one of the marking slots corresponding to the caching process of the two reference bitmaps as the cache mark according to the status variable of the shared object includes:

[0092] S251, the caching process determines whether the status variable is in the update state;

[0093] S253, if it is in the non-update state, then set the marking slot corresponding to the caching process of the first reference bitmap in the two reference bitmaps as the cache mark;

[0094] S255. If it is in the update state, set the flag slot corresponding to the cache process in the second reference bitmap among the two reference bitmaps to the cache flag.

[0095] In this embodiment, the first reference bitmap and the second reference bitmap may have the same structure. In each cycle, the first reference bitmap is used to reflect that the cache process caches the shared objects that have not been modified in this cycle locally, and the second reference bitmap is used to reflect that the cache process caches the shared objects that have been modified in this cycle locally. Thus, when the values of all flag slots in the first reference bitmap are release flags, it indicates that no process caches the unmodified shared objects. When the value of at least one flag slot in the first reference bitmap is a cache flag, it indicates that there is a process caching the unmodified shared objects.

[0096] In some embodiments of the usage method of the present invention, as Figure 3 shown, the step of alternatively setting one of the flag slots corresponding to the release process in the two reference bitmaps to the release flag according to the state variable, the version variable, and the version variable of the release process includes:

[0097] S451. The release process determines whether the version variable is consistent with the version variable of the release process; if not, execute S455, if so, execute S453;

[0098] S453. The release process determines whether the state variable is in the update state; if it is not in the update state, execute S455, if it is in the update state, execute S457;

[0099] S455. Set the flag slot corresponding to the release process in the first reference bitmap to the release flag;

[0100] S457. Set the flag slot corresponding to the release process in the second reference bitmap to the release flag.

[0101] In this embodiment, when the version variable is not consistent with the version variable of the release process, it indicates that the release process cached the shared object in the shared memory locally in the previous cycle, which is equivalent to the situation where the shared object in the shared memory has not been modified in this cycle. Therefore, when the release process releases, it needs to set the flag slot corresponding to the corresponding flag slot in the first reference bitmap to the release flag.

[0102] In this embodiment, when the version variable of the release process is consistent with the version variable in the shared memory, it indicates that the release process caches the shared object in the shared memory locally during this cycle. Therefore, there may be two cases: The first case is that the shared object in the shared memory has not been modified during this cycle. At this time, the status variable is in a non-updated state, and it can be determined that the release process has performed cache marking on the corresponding marked slot of the first reference bitmap when caching the shared object. Now, it is necessary to set this marked slot to the release mark. The second case is that the shared object in the shared memory has been modified during this cycle. At this time, the status variable is in an updated state, and it can be determined that the release process originally cached the modified shared object and has performed cache marking on the corresponding marked slot of the second reference bitmap when caching the shared object. Now, it is necessary to set this marked slot to the release mark. In this way, when the values of all marked slots in the first reference bitmap are release marks, it indicates that all processes have released the unmodified shared object. When at least one of the values of the marked slots in the first reference bitmap is a cache mark, it indicates that there is a process caching an unmodified shared object.

[0103] In some embodiments of the usage method of the present invention, as Figure 4 shown, the update process of the shared object includes:

[0104] S551, the update process modifies the shared object;

[0105] S552, the update process issues a broadcast requesting all other processes to modify their respective shared objects;

[0106] S553, the update process sets the status variable to the updated state;

[0107] S554, determine whether all marked slots in the first reference bitmap are set to release marks;

[0108] S555, if so, the update process sets the status variable to the non-updated state;

[0109] S556, exchange the values of all corresponding marked slots in the first reference bitmap and the second reference bitmap;

[0110] S557, increment the version variable by one.

[0111] This embodiment is used to further optimize the update problem of the database shared object. Specifically, the update process first modifies the value of the shared object to the required value, and then issues a broadcast requesting all other processes to modify their respective shared objects. The processes that have cached this shared object will respond to this broadcast and perform the operation of modifying their shared objects. Then the update process sets the status variable to the updated state to indicate that the shared object in the shared memory has been modified during this cycle.

[0112] It should be understood that after the update process sends a broadcast and sets the status variable to the update state, a process that does not cache the shared object can obtain the modified shared object and cache it locally; since the status variable is in the update state at this time, the caching process needs to set the corresponding marker slot of the second reference bitmap to the cache marker. When a process that has already cached the shared object modifies its shared object, it can first release the old shared object, set the corresponding marker slot in the first reference bitmap to the release marker, then obtain the modified shared object, and set the corresponding marker slot in the second reference bitmap to the cache marker.

[0113] In particular, in this embodiment, when the update process updates the shared object, it does not need to block other processes from obtaining the modified shared object for a long time. That is to say, it does not need to wait for all processes that have cached the shared object to release the old shared object, but directly releases the access permission of each process to the modified shared object. On the one hand, it enables the update process to update the shared object at any time, and on the other hand, it enables other processes to obtain the modified shared object at any time, realizing non-blocking and efficient update and use of the shared object, improving the concurrency when updating the shared object, and enhancing the overall performance of the system.

[0114] After the update process sends a broadcast, it can wait for a period of time until all marker slots in the first reference bitmap are set to the release marker, indicating that the old shared object cache has been released by the process, and then it can perform the operation of ending this round of cycle. Specifically, the update process can exchange the values of all corresponding marker slots in the first reference bitmap and the second reference bitmap, and increment the version variable by one. At this time, all marker slots in the first reference bitmap are in the initial state and no longer have the meaning of maintenance. By exchanging the first reference bitmap and the second reference bitmap, making the second reference bitmap of this round of cycle be the first reference bitmap of the next round of cycle, and using the first reference bitmap in the initial state of this round of cycle as the second reference bitmap of the next round of cycle, the step of reconstructing the two reference bitmaps in the next round of cycle can be omitted.

[0115] In some embodiments of the usage method of the present invention, as Figure 7 shown, the steps for any process that receives the broadcast to modify its shared object include:

[0116] S561, invalidate the shared object cached locally;

[0117] S563, cache the shared object modified by the update process locally.

[0118] Specifically, after the process receives the broadcast, it can first invalidate the shared object cached locally, set the corresponding mark slot of the corresponding reference bitmap to the release mark, then cache the modified shared object in the shared memory locally, and set the corresponding mark slot of the second reference bitmap to the cache mark. In this way, the efficient update of the local shared object is achieved.

[0119] In some embodiments of the usage method of the present invention, such as Figure 4 shown, before the update process modifies the shared object, it further includes:

[0120] S511, in response to the condition for the update process to trigger the update of the shared object, the update process acquires the exclusive lock of the shared object; and

[0121] after the update process sends a broadcast requesting all other processes to modify their respective shared objects, it further includes:

[0122] S513, the update process releases the exclusive lock of the shared object.

[0123] In this embodiment, by acquiring the exclusive lock of the shared object, it can prevent other processes from reading or modifying the shared object when the update process modifies the shared object, avoiding concurrent error problems. In particular, since some processes have cached the shared object locally, there are fewer processes holding the shared lock of the shared object, and the update process can quickly acquire the exclusive lock of the shared object and modify the shared object. In this way, situations such as lock starvation and lock starvation can be effectively reduced or avoided, achieving non-blocking and efficient modification of the shared object, improving the update efficiency of the shared object, enhancing the concurrency when updating the shared object, and improving the overall performance of the system.

[0124] In this embodiment, after the update process sends the broadcast, it can release the exclusive lock of the shared object. In this way, all processes can request to obtain the modified shared object without waiting and cache it locally, achieving non-blocking and efficient use of the shared object and improving the usage efficiency of the database shared object.

[0125] In some embodiments of the usage method of the present invention, such as Figure 4 shown, before the update process sets the status variable to the update state, it further includes:

[0126] S521, the update process acquires the exclusive locks of the status variable and the version variable; and

[0127] after the update process sets the status variable to the update state, it further includes:

[0128] S523, the update process releases the exclusive locks of the status variable and the version variable.

[0129] In this embodiment, the status variable and the version variable use the same lock to reduce the memory occupation of the database. By acquiring the exclusive locks of the status variable and the version variable, it is possible to prevent other processes from reading or modifying the status variable and / or the version variable when the update process modifies the status variable and / or the version variable, thus avoiding concurrent error problems.

[0130] In some embodiments of the usage method of the present invention, as Figure 4 shown, before the update process sets the status variable to the non-update state, it further includes: <>

[0131] S531, the update process acquires the exclusive locks of the status variable and the version variable; and

[0132] After the version variable is incremented by one, it further includes:

[0133] S533, the update process releases the exclusive locks of the status variable and the version variable.

[0134] By acquiring the exclusive locks of the status variable and the version variable, it is possible to prevent other processes from reading or modifying the status variable and / or the version variable when the update process modifies the status variable and / or the version variable, thus avoiding concurrent error problems.

[0135] In some embodiments of the usage method of the present invention, as Figure 3 shown, before the releasing process determines whether the version variable is consistent with the version variable of the releasing process, it further includes:

[0136] S411, the releasing process acquires the shared locks of the status variable and the version variable; and

[0137] After the step of setting the flag slot position corresponding to the releasing process of the first reference bitmap or the second reference bitmap to the release flag, it further includes:

[0138] S413, the releasing process releases the shared locks of the status variable and the version variable.

[0139] By acquiring the shared locks of the status variable and the version variable, it is possible to prevent other processes from modifying the status variable and / or the version variable when the releasing process reads the status variable and / or the version variable, thus avoiding concurrent error problems.

[0140] In some embodiments of the usage method of the present invention, as Figure 2 shown, before the caching process determines whether the status variable is in the update state, it further includes:

[0141] S211, the caching process acquires the shared locks of the status variable and the version variable; and

[0142] After the cache process caches the version variables of the two reference bitmaps locally, it further includes:

[0143] S213, the cache process releases the shared locks of the status variable and the version variable.

[0144] By acquiring the shared locks of the status variable and the version variable, it can prevent other processes from modifying the status variable and / or the version variable when the cache process reads the status variable and / or the version variable, and avoid the problem of concurrent errors.

[0145] In some embodiments of the usage method of the present invention, as Figure 5 shown, the steps for the cache process to cache the shared object locally include:

[0146] S261, acquire the shared lock of the shared object;

[0147] S263, acquire the shared object;

[0148] S265, cache the shared object locally;

[0149] S267, release the shared lock of the shared object.

[0150] By acquiring the shared lock of the shared object, it can prevent other processes from modifying the shared object when the cache process caches the shared object, and avoid the problem of concurrent errors.

[0151] In some embodiments of the usage method of the present invention, as Figure 6 shown, the steps for the release process to release its shared object include:

[0152] S461, in response to the release process triggering an instruction for logging off this process, or receiving a notification to modify its shared object, determine whether the release process has a shared object cached locally;

[0153] S463, if so, release the shared object cached locally.

[0154] In this embodiment, when any process is logged off, it is necessary to first release the shared object cached locally and set the corresponding mark slot of the corresponding reference bitmap to the release mark. When any process receives a notification to modify its shared object (such as a broadcast sent by the update process), it is necessary to determine whether this process has a shared object cached locally. If so, it is necessary to respond to the notification, release the shared object cached locally, and set the corresponding mark slot of the corresponding reference bitmap to the release mark.

[0155] The flowchart provided in this embodiment is not intended to indicate that the operations of the method will be performed in any specific order, or that all operations of the method are included in every case. In addition, the method may include additional operations. Within the scope of the technical concept provided by the method in this embodiment, additional changes may be made to the above method.

[0156] It should be understood that in some embodiments, each part may be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be implemented by software or firmware stored in a memory and executed by a suitable instruction execution system.

[0157] The embodiment of the present invention also provides a computer program product 10, a computer-readable storage medium 20, and a computer device 30. Figure 8 is a schematic diagram of a computer program product 10 according to an embodiment of the present invention, Figure 9 is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention, Figure 10 is a schematic diagram of a computer device 30 according to an embodiment of the present invention. The computer program product 10 includes a computer program 11, and when the computer program 11 is executed by a processor 32, it implements the steps of any one of the above usage methods. The computer-readable storage medium 20 stores the above computer program 11, and when the computer program 11 is executed by a processor 32, it implements the steps of the usage method of any one of the above embodiments. The computer device 30 may include a memory 31, a processor 32, and a computer program 11 stored on the memory 31 and running on the processor 32.

[0158] The computer program 11 for performing the operations of the present invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of an integrated circuit, or source code or object code written in any combination of one or more programming languages and procedural programming languages. The computer program 11 may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of the present invention, an electronic circuit, including, for example, a programmable logic circuit, a field-programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by using state information of the computer-readable program instructions to personalize the electronic circuit.

[0159] For the description of this embodiment, the computer program product 10 is a related product containing the computer program 11.

[0160] For the description of this embodiment, the computer-readable storage medium 20 is a tangible device capable of retaining and storing the computer program 11, which may be any device that can contain, store, communicate, propagate, or transport the computer program 11 for use by or in connection with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the computer-readable storage medium 20 include the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device, and any suitable combination of the above.

[0161] The computer device 30 can be, for example, a server, a desktop computer, a laptop computer, a tablet computer, or a smart phone. In some examples, the computer device 30 can be a cloud computing node. The computer device 30 can be described in the general context of computer system-executable instructions, such as program modules, executed by a computer system. Generally, program modules can include routines, programs, object programs, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer device 30 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can be located on local or remote computing system storage media including storage devices.

[0162] The computer device 30 can include a processor 32 adapted to execute stored instructions and a memory 31 that provides temporary storage space for the operation of the instructions during operation. The processor 32 can be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. The memory 31 can include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0163] The computer device 30 can also include a network adapter / interface and an input / output (I / O) interface. The I / O interface allows data to be input and output with external devices that can be connected to the computer device. The network adapter / interface can provide communication between the computer device and a network, which is generally shown as a communication network.

[0164] At this point, those skilled in the art should recognize that although multiple exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications consistent with the principles of the present invention can still be directly determined or derived from the content disclosed in the present invention without departing from the spirit and scope of the present invention. Therefore, the scope of the present invention should be understood and determined to cover all such other variations or modifications.

Claims

1. A method for using a database shared object, characterized in that, Including: Create two reference bitmaps corresponding to the shared object, and each process in the database maps an independent marker slot in the two reference bitmaps; When any one of the processes caches the shared object locally as a cache process, according to the status variable of the shared object, alternatively set one of the marker slots corresponding to the cache process in the two reference bitmaps to a cache marker, where the status variable reflects whether the shared object is being updated; and The cache process caches the version variables of the two reference bitmaps locally, and the version variables reflect the current versions of the two reference bitmaps; When any one of the processes releases the shared object as a release process, according to the status variable, the version variable, and the version variable of the release process, alternatively set one of the marker slots corresponding to the release process in the two reference bitmaps to a release marker.

2. The usage method according to claim 1, wherein The step of alternatively setting one of the marker slots corresponding to the cache process in the two reference bitmaps to a cache marker according to the status variable of the shared object includes: The cache process determines whether the status variable is in an updated state; If it is not in an updated state, set the marker slot corresponding to the cache process in the first reference bitmap of the two reference bitmaps to the cache marker; If it is in the updated state, set the marker slot corresponding to the cache process in the second reference bitmap of the two reference bitmaps to the cache marker.

3. The usage method according to claim 2, characterized in that, The step of alternatively setting one of the marker slots corresponding to the release process in the two reference bitmaps to a release marker according to the status variable, the version variable, and the version variable of the release process includes: The release process determines whether the version variable and the version variable of the release process are consistent; If they are not consistent, set the marker slot corresponding to the release process in the first reference bitmap to the release marker; If they are consistent, the release process determines whether the status variable is in the updated state; If it is not in the updated state, set the marker slot corresponding to the release process in the first reference bitmap to the release marker; If it is in the updated state, set the marker slot corresponding to the release process in the second reference bitmap to the release marker.

4. The usage method according to claim 3, characterized in that, The update process of the shared object includes: In response to a condition that any one of the processes triggers an update to the shared object as an update process, the update process modifies the shared object; The update process sends a broadcast requesting all other processes to modify their respective shared objects; The update process sets the status variable to the updated state; In response to all the marker slots in the first reference bitmap being set to the release marker, the update process sets the status variable to the non-updated state; Exchange the values of all the corresponding marker slots in the first reference bitmap and the second reference bitmap; Increment the version variable by one; Wherein, the step of any one of the processes that receives the broadcast modifying its shared object includes: Invalidate the shared object cached locally; Cache the shared object modified by the update process locally.

5. The usage method according to claim 4, wherein Before the update process modifies the shared object, it further includes: The update process acquires an exclusive lock on the shared object; and After the update process issues a broadcast requesting all other processes to modify their respective shared objects, it further includes: The update process releases the exclusive lock on the shared object; Before the update process sets the status variable to the update status, it further includes: The update process acquires an exclusive lock on the status variable and the version variable; and after the update process sets the status variable to the update status, it further includes: The update process releases the exclusive lock on the status variable and the version variable; Before the update process sets the status variable to the non-update status, it further includes: The update process acquires an exclusive lock on the status variable and the version variable; and after incrementing the version variable by one, it further includes: The update process releases the exclusive lock on the status variable and the version variable.

6. The usage method according to claim 3, wherein Before the release process determines whether the version variable is consistent with the version variable of the release process, it further includes: The release process acquires a shared lock on the status variable and the version variable; and after setting the flag slot corresponding to the release process of the first reference bitmap or the second reference bitmap to the release flag, it further includes: The release process releases the shared lock on the status variable and the version variable.

7. The usage method according to claim 2, wherein Before the caching process determines whether the status variable is in the update status, it further includes: The caching process acquires a shared lock on the status variable and the version variable; and after the caching process caches the version variables of the two reference bitmaps locally, it further includes: The caching process releases the shared lock on the status variable and the version variable.

8. The usage method according to claim 1, characterized in that, The step of the caching process caching the shared object locally includes: Acquire a shared lock on the shared object; Acquire the shared object; Cache the shared object locally; Release the shared lock on the shared object.

9. The usage method according to claim 1, characterized in that, The step of the release process releasing its shared object includes: In response to the release process triggering an instruction for logging off the current process, or receiving a notification to modify its shared object, determine whether there is a shared object cached locally by the release process; If so, release the shared object cached locally.

10. A computer-readable storage medium, characterized in that, A computer program is stored thereon, and when the computer program is executed by a processor, it implements the steps of the usage method of the database shared object according to any one of claims 1 to 9.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the usage method of the database shared object according to any one of claims 1 to 9.

12. A computer device, characterized in that, Comprising a memory, a processor, and a computer program stored on the memory, the processor executes the computer program to implement the steps of the method for using a database sharing object according to any one of claims 1 to 9.