Virtual item status management methods, devices, storage media and electronic devices

Abstract

This application discloses a virtual item state management method, including: upon receiving a state change request for a first record, determining the target time period information of the first record, wherein the first record is a management record used to record the quantity information of virtual items associated with a target object within the target time period; if the target time period information represents a first type of time period, performing a state change on the first record based on a locking interaction mechanism, wherein the first type of time period is the minimum time period for generating the management record; if the target time period information represents a second type of time period, querying all second records associated with the first record, wherein the second type of time period includes multiple first type of time periods; and if the first record is not associated with any second record, performing a state change on the first record based on the locking interaction mechanism. This application ensures that multiple virtual items are not generated.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to virtual item status management methods, apparatus, storage media and electronic devices. Background Technology

[0002] With the continuous development of the online world, the management of virtual item circulation has become increasingly important. Virtual item management platforms can distribute virtual items to users based on their behavior. To meet users' needs for acquiring virtual items across multiple time dimensions, virtual item management platforms can support virtual item distribution functions across these dimensions. However, this multi-time dimension also significantly increases the difficulty of virtual item management and leads to problems such as under-distribution or over-distribution, thus reducing the accuracy of virtual item management in related technologies. Summary of the Invention

[0003] To address at least one of the aforementioned technical problems, embodiments of this application provide a method, apparatus, storage medium, and electronic device for virtual item status management.

[0004] On one hand, embodiments of this application provide a method for managing the status of virtual items, the method comprising:

[0005] Upon receiving a status change request for the first record, the target time period information of the first record is determined, wherein the first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period;

[0006] When the target time period information represents the first type of time period, the state of the first record is changed based on the locking interaction mechanism, and the first type of time period is the minimum time period for generating management records;

[0007] When the target time period information represents a second type of time period, all second records associated with the first record are queried. The time period corresponding to each second record is located in the target time period, and the time period information corresponding to each second record is the first type of time period. The second type of time period includes multiple first type of time periods.

[0008] If the first record is not associated with any second record, the state of the first record is changed based on the locking interaction mechanism.

[0009] In one embodiment, the method further includes:

[0010] When all second records associated with the first record are in the first state, the state of the first record is changed based on the locking interaction mechanism;

[0011] The first state indicates that the virtual item associated with its corresponding second record has been sent to the target object.

[0012] In one embodiment, the method further includes:

[0013] If a second target record exists, the system indicates that the response to the state change request for the first record failed.

[0014] Display a status change notification for the target second record. The status change notification is used to prompt the user to change the status of the target second record back to the first status by performing relevant operations, or to delete the target second record.

[0015] The target second record is a second record that is not in the first state.

[0016] In one embodiment, the status change request is a preview request, which is used to change the first record to a second status. Before determining the target time period information of the first record upon receiving a status change request for the first record, the method further includes:

[0017] Acquire behavioral performance information, which is the performance information of the target object related to virtual items during the target time period;

[0018] A first record is generated based on the first identifier, the second identifier, and the behavioral performance information. The first identifier is the identifier of the virtual item provider corresponding to the target object, and the second identifier is the identifier of the virtual item manager corresponding to the target object.

[0019] The preview request is generated based on the first record;

[0020] or,

[0021] The status change request is an inbound request, which is used to change the first record to a third status. Before determining the target time period information of the first record upon receiving a status change request for the first record, the process further includes:

[0022] Acquire behavioral performance information, which is the performance information of the target object related to virtual items during the target time period;

[0023] A first record is generated based on the first identifier, the second identifier, and the behavioral performance information. The first identifier is the identifier of the virtual item provider corresponding to the target object, and the second identifier is the identifier of the virtual item manager corresponding to the target object.

[0024] The inbound request is generated based on the first record.

[0025] In one embodiment, generating the first record based on the first identifier, the second identifier, and the behavioral performance information includes:

[0026] The first record is generated based on the first identifier, the second identifier, the third identifier, and the behavioral performance information, wherein the third identifier is the identity identifier of the target object.

[0027] In one embodiment, the state change of the first record based on the locking interaction mechanism includes:

[0028] Query the third record, which is a record that has the same primary key and the same target time period as the first record;

[0029] If the third record is not found, a status change process is performed;

[0030] If the third record is found, the lock record corresponding to the third record is queried. The lock record is used to prevent other threads, except the thread that takes over the lock record, from processing records that have the same primary key as the third record.

[0031] If a lock record exists and the lock duration corresponding to the lock record is greater than a preset threshold, a state change process is performed.

[0032] In one embodiment, the method further includes:

[0033] If a lock record exists and the lock duration corresponding to the lock record is less than or equal to the preset threshold, a message will be displayed indicating that the response to the state change request for the first record has failed.

[0034] In one embodiment, the state change processing when the third record is not found includes:

[0035] Generate a third record corresponding to the first record, and generate a lock record based on the third record;

[0036] Once the lock record has been generated, the third record will undergo a status change.

[0037] If the status change is successful, the lock record is deleted.

[0038] In one embodiment, the state change processing when a lock record exists and the lock duration corresponding to the lock record exceeds a preset threshold includes:

[0039] Take over the lock record and reset the lock time of the lock record;

[0040] Once the lock record has been generated, the third record will undergo a status change.

[0041] If the status change is successful, the lock record is deleted.

[0042] On the other hand, embodiments of this application provide a virtual item status management device, the device comprising:

[0043] The status change request module is used to determine the target time period information of the first record when a status change request for the first record is received. The first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period.

[0044] The status change response module is used to perform the following operations:

[0045] When the target time period information represents the first type of time period, the state of the first record is changed based on the locking interaction mechanism, and the first type of time period is the minimum time period for generating management records;

[0046] When the target time period information represents a second type of time period, all second records associated with the first record are queried. The time period corresponding to each second record is located in the target time period, and the time period information corresponding to each second record is the first type of time period. The second type of time period includes multiple first type of time periods.

[0047] If the first record is not associated with any second record, the state of the first record is changed based on the locking interaction mechanism.

[0048] In one embodiment, the state change response module is configured to perform the following operations:

[0049] When all second records associated with the first record are in the first state, the state of the first record is changed based on the locking interaction mechanism;

[0050] The first state indicates that the virtual item associated with its corresponding second record has been sent to the target object.

[0051] In one embodiment, the state change response module is configured to perform the following operations:

[0052] If a second target record exists, the system indicates that the response to the state change request for the first record failed.

[0053] Display a status change notification for the target second record. The status change notification is used to prompt the user to change the status of the target second record back to the first status by performing relevant operations, or to delete the target second record.

[0054] The target second record is a second record that is not in the first state.

[0055] In one embodiment, the state change request module is configured to perform the following operation: obtain behavioral performance information, wherein the behavioral performance information is the performance information of the target object related to virtual items during the target time period;

[0056] A first record is generated based on the first identifier, the second identifier, and the behavioral performance information. The first identifier is the identifier of the virtual item provider corresponding to the target object, and the second identifier is the identifier of the virtual item manager corresponding to the target object.

[0057] The preview request is generated based on the first record;

[0058] or,

[0059] The status change request is an inbound request, which is used to change the first record to a third status. Before determining the target time period information of the first record upon receiving a status change request for the first record, the process further includes:

[0060] Acquire behavioral performance information, which is the performance information of the target object related to virtual items during the target time period;

[0061] A first record is generated based on the first identifier, the second identifier, and the behavioral performance information. The first identifier is the identifier of the virtual item provider corresponding to the target object, and the second identifier is the identifier of the virtual item manager corresponding to the target object.

[0062] The inbound request is generated based on the first record.

[0063] In one embodiment, generating the first record based on the first identifier, the second identifier, and the behavioral performance information includes:

[0064] The first record is generated based on the first identifier, the second identifier, the third identifier, and the behavioral performance information, wherein the third identifier is the identity identifier of the target object.

[0065] In one embodiment, the state change response module is configured to perform the following operation: query a third record, wherein the third record is a record that has the same primary key as the first record and has the same target time period;

[0066] If the third record is not found, a status change process is performed;

[0067] If the third record is found, the lock record corresponding to the third record is queried. The lock record is used to prevent other threads, except the thread that takes over the lock record, from processing records that have the same primary key as the third record.

[0068] If a lock record exists and the lock duration corresponding to the lock record is greater than a preset threshold, a state change process is performed.

[0069] In one embodiment, the state change response module is configured to perform the following operation: if a lock record exists and the lock duration corresponding to the lock record is less than or equal to the preset threshold, indicate that the response to the state change request for the first record has failed.

[0070] In one embodiment, the state change processing when the third record is not found includes:

[0071] Generate a third record corresponding to the first record, and generate a lock record based on the third record;

[0072] Once the lock record has been generated, the third record will undergo a status change.

[0073] If the status change is successful, the lock record is deleted.

[0074] In one embodiment, the state change response module is configured to perform the following operations: take over the lock record and reset the locking time of the lock record;

[0075] Once the lock record has been generated, the third record will undergo a status change.

[0076] If the status change is successful, the lock record is deleted.

[0077] On the other hand, embodiments of this application provide a computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the above-described virtual item state management method.

[0078] On the other hand, embodiments of this application provide an electronic device, including at least one processor and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the at least one processor implements the above-described virtual item state management method by executing the instructions stored in the memory.

[0079] On the other hand, embodiments of this application provide a computer program product, including a computer program or instructions, which, when executed by a processor, implement the aforementioned virtual item state management method.

[0080] This application provides a virtual item state management method. The state of a first record is changed only when it is fully considered to ensure that multiple issuances will not occur. In this application, the state change of the first record is directly related to the issuance of virtual items. Therefore, the state management method in this application ensures that multiple issuances of virtual items do not occur by rigorously managing the state changes of the first record. Furthermore, this application avoids the problem of multiple issuances in the virtual item issuance process outside of the minimum time period, while not limiting the issuance of virtual items within the minimum time period. Issuance of items within the minimum time period can be carried out directly. This solution reduces the impact of state management on the issuance process within the minimum time period while ensuring that virtual item issuance can be carried out in all time periods without ultimately preventing multiple issuances. Attached Figure Description

[0081] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or related technologies, the drawings used in the description of the embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0082] Figure 1 This is a flowchart illustrating a virtual item status management method provided in the embodiments of this specification;

[0083] Figure 2 This is a schematic diagram of the method for changing the state of the first record based on the locking interaction mechanism provided in the embodiments of this specification;

[0084] Figure 3 This is a block diagram of the virtual item status management device provided in the embodiments of this application;

[0085] Figure 4 This is a schematic diagram of the hardware structure of a device for implementing the method provided in the embodiments of this application. Detailed Implementation

[0086] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of the embodiments of this application.

[0087] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of the embodiments of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the present application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to these processes, methods, products, or devices.

[0088] To make the objectives, technical solutions, and advantages disclosed in the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely illustrative of the embodiments of this application and are not intended to limit the embodiments of this application.

[0089] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this embodiment, unless otherwise stated, "a plurality of" means two or more.

[0090] This application provides a virtual item status management method, which is applied to a virtual item management terminal. The application scenarios of the virtual item management terminal are described below.

[0091] As an intermediate management platform, the virtual item management terminal can communicate with the user's electronic devices (including the client that logs into the user's account) and the task publishing platform, thereby decoupling the functions of the task publishing platform and eliminating the need for the task publishing platform to manage virtual items.

[0092] This application does not limit the task publishing platform; it can be considered any task publishing platform connected to the aforementioned virtual item management terminal, or any task publishing platform that subscribes to the virtual item management service of the aforementioned virtual item management terminal. For example, the task publishing platform can be a game program server, which can publish game tasks to users, but users can obtain virtual item rewards from the game tasks through the virtual item management terminal in this application embodiment, and the server can decouple the management functions related to virtual item rewards in the game tasks. As another example, the task publishing platform can be a live streaming program server, which can publish live streaming tasks to users, but users can obtain virtual item rewards from the live streaming tasks through the virtual item management terminal in this application embodiment, and the server can decouple the management functions related to virtual item rewards in the live streaming tasks. This application does not limit the type or number of task publishing platforms connected.

[0093] The target object in this application embodiment can be understood as the virtual object corresponding to a user who performs a task on any of the aforementioned task publishing platforms. The target object should receive virtual items issued by the task publishing platform as a reward for performing the task. However, the virtual items in this application embodiment can be issued by the virtual item management terminal. That is, the task publishing platform can entrust the virtual item management terminal to issue the virtual items by signing a service agreement.

[0094] It should be noted that the virtual item management terminal in this application embodiment can provide delivery services for the target object at different time dimensions. For example, it can deliver virtual items on a weekly or monthly basis according to the target object's behavior on the task publishing platform, thereby supporting the delivery of virtual items at multiple time dimensions and meeting the user's needs for obtaining virtual items at multiple time dimensions. For example, the virtual item management terminal can deliver a portion of virtual items to the user weekly and another portion of virtual items to the user monthly, thereby meeting the user's needs for obtaining virtual items at multiple time dimensions.

[0095] However, satisfying the demand for virtual items across multiple time dimensions brings challenges to virtual item management; specifically, this feature introduces difficulties in managing the status of virtual item management records. Inaccurate management of the status of virtual item management records could lead to the proliferation of virtual items.

[0096] For example, based on the behavior information of an object A from August 7th to August 13th, a virtual item worth 500 virtual coins is issued to it in the corresponding "week". Of course, there is a corresponding record in the virtual item management terminal, namely record 1. Assuming that the state of record 1 is state 1 at this time, it means that the virtual item in record 1 has been issued.

[0097] When distributing virtual items monthly, based on the behavior of object A in August, virtual items worth 5000 virtual coins should be distributed to them. Of course, there is a corresponding record in the virtual item management terminal, namely record 2. Assuming that the status of record 2 is state 2 at this time, it means that the virtual items in record 2 have not yet been distributed.

[0098] When determining the virtual items to be distributed in August based on Record 1 and Record 2 and their respective states, normally 5000-500=4500 virtual items should be distributed. However, because the order in which Record 1 and Record 2 are generated is not unique, and the order in which the states of Record 1 and Record 2 change cannot be preset, the final total amount of virtual items to be distributed monthly based on Record 1 and Record 2 and their respective states may be inaccurate, resulting in over-distribution issues.

[0099] For example, suppose record 1 is generated first, but because the virtual item worth 500 virtual coins has not yet been distributed, the state of record 1 is not state 1. In this case, if record 2 is generated, the virtual item requested in both record 1 and record 2 may be distributed, that is, 5000 + 500 = 5500 virtual items will be distributed, resulting in over-distribution.

[0100] To address the challenges of managing the status of virtual items in multi-time-dimensional virtual item acquisition functions, ensure that virtual items are not duplicated, and achieve accurate circulation of virtual items, this application provides a virtual item status management method.

[0101] Based on the application scenarios mentioned above, in this scenario, Figure 1 This document illustrates a flowchart of a virtual item status management method provided in an embodiment of this application. This method also runs on a virtual item management terminal. The embodiments of this application provide the method operation steps described in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many steps and does not represent the only execution order. In actual systems, terminal devices, or server products, the method can be executed sequentially according to the embodiments or accompanying drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). The above method may include:

[0102] S101. Upon receiving a status change request for the first record, determine the target time period information of the first record, wherein the first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period.

[0103] In this embodiment, the aforementioned status change request can be a preview request or an entry request. A preview request provides the client with a preview function for management records. An entry request provides the client with both preview and entry functions for management records. In this embodiment, only virtual items in management records that have been entered into the database and set to the first state can be distributed to their corresponding objects.

[0104] In this embodiment, the state of the management record after the preview request is implemented is referred to as the second state, in which the management record has not been entered into the database. In this embodiment, the state of the management record after the entry request is implemented is referred to as the third state, in which the management record has been entered into the database but has not yet taken effect. This is the difference between the third state and the first state.

[0105] For the first record, if a preview request is received, the client can view the content related to the first record by accessing the virtual item management terminal. However, the content of the first record has not yet been entered into the database of the virtual item management terminal, meaning the first record can be set to the second state. If an entry request is received for the first record, the client can view the content related to the first record by accessing the virtual item management terminal and enter the content of the first record into the database of the virtual item management terminal, meaning the first record can be set to the third state.

[0106] Taking the aforementioned status change request as a preview request as an example, before determining the target time period information of the first record upon receiving the status change request for the first record, the process further includes:

[0107] S201. Obtain behavioral performance information, which is the performance information of the target object in the target time period related to virtual items.

[0108] For example, if a target receives virtual items by completing a game task on task publishing platform 1, then the behavioral information refers to the target's game task execution status during the target time period. If a target receives virtual items by completing a media resource editing task on task publishing platform 2, then the behavioral information refers to the target's media resource editing task execution status during the target time period.

[0109] S202. Based on the first identifier, the second identifier, and the aforementioned behavioral performance information, generate a first record, wherein the first identifier is the identifier of the virtual item provider corresponding to the aforementioned target object, and the second identifier is the identifier of the virtual item manager corresponding to the aforementioned target object.

[0110] The first identifier can be the identifier of task publishing platform 1 or task publishing platform 2, and the second identifier can be the identifier of an administrator belonging to the virtual item management terminal. The virtual item management terminal can be configured with multiple administrators, each of whom is responsible for managing the task execution status of multiple users on various task publishing platforms, as well as managing the corresponding management records for these multiple users on the virtual item management terminal. In this case, the primary key of the generated first record is "first identifier and second identifier".

[0111] S203. Generate the preview request based on the first record mentioned above.

[0112] Taking the aforementioned status change request as an inbound request as an example, the inbound request is used to change the aforementioned first record to the third status. Before determining the target time period information of the aforementioned first record upon receiving the status change request for the first record, the process further includes:

[0113] S301. Obtain behavioral performance information, wherein the behavioral performance information is the performance information of the target object in the target time period related to the virtual item.

[0114] S302. Based on the first identifier, the second identifier, and the aforementioned behavioral performance information, generate a first record, wherein the first identifier is the identifier of the virtual item provider corresponding to the target object, and the second identifier is the identifier of the virtual item manager corresponding to the target object.

[0115] S303. Generate the above-mentioned inbound request based on the first record.

[0116] The generation method for the inbound request is similar to that of the preview request, and will not be repeated in this embodiment. Both the inbound request and the preview request can be triggered and generated by the administrator of the virtual item management terminal and transmitted to the virtual item management terminal. In a specific embodiment, generating a first record based on the first identifier, the second identifier, and the aforementioned behavioral information can specifically include: generating the first record based on the first identifier, the second identifier, the third identifier, and the aforementioned behavioral information, where the third identifier is the identity identifier of the target object. In this case, the primary key of the generated first record is "first identifier and second identifier and third identifier". The primary key setting is more granular than that described above, enabling more refined management of the record's status.

[0117] This application embodiment supports the state transition of management records under multiple time dimensions. For example, it can support weekly and monthly dimensions. If the target time period information represents the weekly dimension, then the first record records the quantity information of virtual items within a week; if the target time period information represents the monthly dimension, then the first record records the quantity information of virtual items within a month.

[0118] S102. When the target time period information represents the first type of time period, the state of the first record is changed based on the locking interaction mechanism. The first type of time period is the minimum time period for generating management records.

[0119] In this embodiment, the first type of time period is the minimum time period for generating management records. Taking the virtual item management terminal as supporting weekly and monthly dimensions as an example, the first type of time period is "week". For this type of time period-related first record, the state of the first record can be changed directly based on the locking interaction mechanism. This is because this embodiment avoids the problem of multiple issuances in the virtual item issuance process under non-minimum time periods, while not limiting the issuance of virtual items under the minimum time period. The issuance of items under the minimum time period can be carried out directly. This solution reduces the impact of state management on the issuance process under the minimum time period, and ensures that virtual item issuance can be carried out in all time periods without the technical effect of multiple issuances.

[0120] S103. When the target time period information represents the second type of time period, query all the second records associated with the first record. The time period corresponding to each second record is located in the target time period, and the time period information corresponding to each second record is the first type of time period. The second type of time period includes multiple first type of time periods.

[0121] The second type of time period is obviously not the minimum time period. Taking the virtual item management terminal as an example, which supports weekly and monthly dimensions, the second type of time period is "month". First, you can query the records related to each "week" in that month, that is, all the second records mentioned above.

[0122] S104. If the first record is not associated with any second record, the state of the first record is changed based on the locking interaction mechanism.

[0123] If the first record is not associated with any second record, it means that there are no virtual items paid out weekly that month. Therefore, there will be no over-issuance due to the weekly payment of virtual items. Virtual items can be distributed directly based on the first record on a monthly basis without over-issuance.

[0124] In this embodiment, the state change of the first record based on the locking interaction mechanism is considered to be performed only after fully considering that it will not lead to multiple issuances. This is because the state change of the first record in this embodiment is directly related to the issuance of virtual items. Therefore, the state management method in this embodiment ensures that multiple issuances of virtual items do not occur by strictly managing the state change of the first record.

[0125] In one embodiment, when all second records associated with the first record are in the first state, the state of the first record is changed based on the locking interaction mechanism; the first state indicates that the virtual item associated with the corresponding second record has been sent to the target object.

[0126] In other words, if there is a situation in the month where virtual items may need to be issued weekly, i.e. there is a second record, if these second records are all in the first state, that is, the virtual items in these second records have been settled weekly, then when settling virtual items monthly, it is only necessary to deduct these pre-settled virtual items, and there will be no over-issuance. In this case, the state of the first record can also be changed based on the locking interaction mechanism.

[0127] In one embodiment, if a target second record exists, a message is displayed indicating that the response to the status change request for the first record failed; a status change reminder for the target second record is displayed, which prompts the user to change the status of the target second record back to the first state by performing relevant operations, or to delete the target second record; wherein the target second record is a second record that is not in the first state.

[0128] If a second record (target second record) exists that is not in the first state, it indicates that virtual items in the target second record are ready to be distributed weekly, but this action has not yet been implemented. Therefore, it is possible that after the virtual items are distributed monthly, the virtual items in the target second record will be settled again, resulting in over-distribution. In this case, this application embodiment directly disallows the state change of the first record and indicates that the response to the aforementioned request for a state change of the first record has failed. The distribution of virtual items in the first record is only triggered when the first record is in the first state. Preventing the state change of the first record prevents the distribution of virtual items in the first record, thereby avoiding over-distribution. Only after the target second record has been properly handled can the state change of the first record be performed again to ensure that over-distribution does not occur.

[0129] In this embodiment of the application, to ensure the uniqueness of operations on the first record, a locking interaction mechanism is needed to change the state of the first record. For example, if two administrators trigger state change requests for the first record sequentially, without locking interaction processing, the two administrators' actions may interfere with each other. The second administrator might see the first record uploaded by the first administrator, not the one they uploaded, causing confusion in the preview or database entry. To ensure that preview and database entry do not become confused in this scenario, such as... Figure 2 As shown, the embodiments of this application perform the following operations:

[0130] S401. Query the third record, which is a record that has the same primary key and the same target time period as the first record.

[0131] S402. If the third record mentioned above is not found, perform a status change.

[0132] If the third record does not exist, it means that no administrator has previously uploaded a record for this target object and this target time period. In other words, the first record is a completely new record, and in this case, a state change can be triggered directly. Specifically, the first record mentioned above can be generated, and a lock record can be generated based on the first record. After the lock record is generated, the state of the first record is changed to the second or third state mentioned above. If the state change is successful, the lock record is deleted. Specifically, if it is a preview request, it is changed to the second state; if it is a database insertion request, it is changed to the third state. Of course, a database insertion operation also needs to be performed, but the database insertion operation is not the focus of this application and will not be elaborated on.

[0133] S403. If the third record is found, query the lock record corresponding to the third record. The lock record is used to prevent other threads, except the thread that takes over the lock record, from processing records that have the same primary key as the third record.

[0134] If a third record exists, it indicates that the first record is not a new record; another administrator has already uploaded data for the target object and the target time period. In this case, it is necessary to query the status of the lock record corresponding to the third record. The lock added in this embodiment is a request-exclusive lock, or a thread-exclusive lock, designed to prevent threads other than the thread currently managing the lock record from processing records with the same primary key as the third record. Since the first and third records have the same primary key, other threads, except the thread currently managing the lock record corresponding to the third record, cannot operate on the first and third records. The current thread is not the managing thread of the lock record corresponding to the third record, and therefore cannot change the state of the first record. In other words, if the lock record is valid, it may prevent the current thread from performing a state change operation.

[0135] S404. If a lock record exists and the lock duration corresponding to the lock record is less than or equal to the preset threshold, indicate that the response to the state change request for the first record failed.

[0136] In this case, the lock is effective, so the state change processing operation that the current thread is about to perform is blocked, the response fails, and the possible preview or database entry chaos is successfully avoided.

[0137] S405. If a lock record exists and the lock duration corresponding to the lock record is greater than a preset threshold, perform a state change process.

[0138] In this scenario, although the lock exists, its duration is excessive. Normally, state transitions shouldn't take long; the lock should be released quickly. An excessively long lock duration likely indicates an anomaly such as service restart, network fluctuations, or program defects. In this case, the thread that acquired the lock may have become invalid, preventing preview or database inconsistencies. The current thread can still perform state change processing. This approach avoids long-term locking due to anomalies, ensuring the normal execution of state changes.

[0139] In this case, the lock record can be taken over and the locking time of the lock record can be reset; after the lock record is generated, the first record is generated based on the third record, and the state of the first record is changed to the second or third state; if the state change is successful, the lock record is deleted.

[0140] Please refer to Figure 3 The diagram illustrates a block diagram of a virtual item status management device in this embodiment, the device comprising:

[0141] The status change request module 301 is used to determine the target time period information of the first record when a status change request for the first record is received. The first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period.

[0142] The status change response module 302 is used to perform the following operations:

[0143] Given that the target time period information represents the first type of time period, the state of the first record is changed based on the locking interaction mechanism. The first type of time period is the minimum time period for generating management records.

[0144] When the target time period information represents the second type of time period, query all the second records associated with the first record. The time period corresponding to each second record is located in the target time period, and the time period information corresponding to each second record is the first type of time period. The second type of time period includes multiple first type of time periods.

[0145] If the first record is not associated with any second record, the state of the first record is changed based on the locking interaction mechanism.

[0146] In one embodiment, the state change response module is configured to perform the following operations:

[0147] When all second records associated with the first record are in the first state, the state of the first record is changed based on the locking interaction mechanism.

[0148] The aforementioned first state indicates that the virtual item associated with its corresponding second record has been sent to the aforementioned target object.

[0149] In one embodiment, the state change response module is configured to perform the following operations:

[0150] If a second target record exists, the system indicates that the response to the status change request for the first record failed.

[0151] Display a status change notification for the aforementioned target second record. The status change notification is used to prompt the user to change the status of the aforementioned target second record back to the aforementioned first status by performing relevant operations, or to delete the aforementioned target second record.

[0152] Among them, the aforementioned target second record is a second record that is not in the aforementioned first state.

[0153] In one embodiment, the state change request module is configured to perform the following operation: obtain behavioral performance information, wherein the behavioral performance information is the performance information of the target object in the target time period that corresponds to the behavior related to the virtual item;

[0154] Based on the first identifier, the second identifier, and the aforementioned behavioral information, a first record is generated. The first identifier is the identifier of the virtual item provider corresponding to the target object, and the second identifier is the identifier of the virtual item manager corresponding to the target object.

[0155] The above preview request is generated based on the first record mentioned above;

[0156] or,

[0157] The aforementioned status change request is an inbound request, used to change the aforementioned first record to the third status. Before determining the target time period information of the aforementioned first record upon receiving a status change request for the first record, the process further includes:

[0158] Obtain behavioral performance information, which is the performance information of the target object related to virtual items during the target time period;

[0159] Based on the first identifier, the second identifier, and the aforementioned behavioral information, a first record is generated. The first identifier is the identifier of the virtual item provider corresponding to the target object, and the second identifier is the identifier of the virtual item manager corresponding to the target object.

[0160] The above-mentioned inbound request is generated based on the first record.

[0161] In one embodiment, generating the first record based on the first identifier, the second identifier, and the aforementioned behavioral performance information includes:

[0162] Based on the first identifier, the second identifier, the third identifier, and the behavioral information, the first record is generated, and the third identifier is the identity identifier of the target object.

[0163] In one embodiment, the state change response module is configured to perform the following operation: query a third record, wherein the third record is a record that has the same primary key and the same target time period as the first record;

[0164] If the aforementioned third record is not found, proceed with the status change process;

[0165] If the third record is found, the corresponding lock record is queried. The lock record is used to prevent other threads, except the thread that takes over the lock record, from processing records that have the same primary key as the third record.

[0166] If a lock record exists and the lock duration corresponding to the lock record exceeds a preset threshold, a state change process is performed.

[0167] In one embodiment, the state change response module is configured to perform the following operation: if a lock record exists and the locking duration corresponding to the lock record is less than or equal to the preset threshold, the module indicates that the response to the state change request for the first record has failed.

[0168] In one embodiment, the above-mentioned status change processing when the third record is not found includes:

[0169] Generate a third record corresponding to the first record mentioned above, and generate a lock record based on the third record;

[0170] Once the above lock record has been generated, the state of the third record will be changed.

[0171] If the above status change is successful, delete the above lock record.

[0172] In one embodiment, the state change response module is configured to perform the following operations: take over the lock record and reset the locking time of the lock record;

[0173] Once the above lock record has been generated, the state of the third record will be changed.

[0174] If the above status change is successful, delete the above lock record.

[0175] The device embodiments and method embodiments are based on the same inventive concept, and will not be described in detail.

[0176] On the other hand, embodiments of this application provide a computer-readable storage medium storing at least one instruction or at least one program, wherein the at least one instruction or at least one program is loaded and executed by a processor to implement the aforementioned virtual item state management method.

[0177] The apparatus portion of the embodiments in this application is based on the same inventive concept as the method embodiment, and will not be described in detail here.

[0178] Furthermore, Figure 4 A schematic diagram of a hardware structure for implementing the method provided in the embodiments of this application is shown. This device can participate in or include the apparatus or system provided in the embodiments of this application. Figure 4 As shown, device 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of the I / O interface), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 4 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, device 10 may also include a... Figure 4 The more or fewer components shown, or having the same Figure 4 The different configurations shown.

[0179] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuitry are generally referred to herein as "data processing circuitry". This data processing circuitry may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be wholly or partially integrated into any other element within device 10 (or mobile device). As involved in the embodiments of this application, this data processing circuitry serves as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0180] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the method described in the embodiments of this application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the virtual item state management method described above. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the device 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0181] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of device 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a radio frequency (RF) module used for wireless communication with the Internet.

[0182] The display may be, for example, a touchscreen liquid crystal display (LCD) that allows a user to interact with the user interface of device 10 (or a mobile device).

[0183] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired result. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0184] The embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and server embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0185] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0186] The instructions in the aforementioned storage medium can execute a virtual item state management method, the method including:

[0187] Upon receiving a status change request for the first record, the target time period information of the first record is determined. The first record is a management record used to record the quantity information of virtual items associated with the target object within the target time period.

[0188] Given that the target time period information represents the first type of time period, the state of the first record is changed based on the locking interaction mechanism. The first type of time period is the minimum time period for generating management records.

[0189] When the target time period information represents the second type of time period, query all the second records associated with the first record. The time period corresponding to each second record is located in the target time period, and the time period information corresponding to each second record is the first type of time period. The second type of time period includes multiple first type of time periods.

[0190] If the first record is not associated with any second record, the state of the first record is changed based on the locking interaction mechanism.

[0191] In one embodiment, the above method further includes:

[0192] When all second records associated with the first record are in the first state, the state of the first record is changed based on the locking interaction mechanism.

[0193] The aforementioned first state indicates that the virtual item associated with its corresponding second record has been sent to the aforementioned target object.

[0194] In one embodiment, the above method further includes:

[0195] If a second target record exists, the system indicates that the response to the status change request for the first record failed.

[0196] Display a status change notification for the aforementioned target second record. The status change notification is used to prompt the user to change the status of the aforementioned target second record back to the aforementioned first status by performing relevant operations, or to delete the aforementioned target second record.

[0197] Among them, the aforementioned target second record is a second record that is not in the aforementioned first state.

[0198] In one embodiment, the aforementioned status change request is a preview request, which is used to change the first record to a second status. Before determining the target time period information of the first record upon receiving a status change request for the first record, the method further includes:

[0199] Obtain behavioral performance information, which is the performance information of the target object related to virtual items during the target time period;

[0200] Based on the first identifier, the second identifier, and the aforementioned behavioral information, a first record is generated. The first identifier is the identifier of the virtual item provider corresponding to the target object, and the second identifier is the identifier of the virtual item manager corresponding to the target object.

[0201] The above preview request is generated based on the first record mentioned above;

[0202] or,

[0203] The aforementioned status change request is an inbound request, used to change the aforementioned first record to the third status. Before determining the target time period information of the aforementioned first record upon receiving a status change request for the first record, the process further includes:

[0204] Obtain behavioral performance information, which is the performance information of the target object related to virtual items during the target time period;

[0205] Based on the first identifier, the second identifier, and the aforementioned behavioral information, a first record is generated. The first identifier is the identifier of the virtual item provider corresponding to the target object, and the second identifier is the identifier of the virtual item manager corresponding to the target object.

[0206] The above-mentioned inbound request is generated based on the first record.

[0207] In one embodiment, generating the first record based on the first identifier, the second identifier, and the aforementioned behavioral performance information includes:

[0208] Based on the first identifier, the second identifier, the third identifier, and the behavioral information, the first record is generated, and the third identifier is the identity identifier of the target object.

[0209] In one embodiment, the aforementioned state change of the first record based on the locking interaction mechanism includes:

[0210] Query the third record, which is a record that has the same primary key and the same target time period as the first record.

[0211] If the aforementioned third record is not found, proceed with the status change process;

[0212] If the third record is found, the corresponding lock record is queried. The lock record is used to prevent other threads, except the thread that takes over the lock record, from processing records that have the same primary key as the third record.

[0213] If a lock record exists and the lock duration corresponding to the lock record exceeds a preset threshold, a state change process is performed.

[0214] In one embodiment, the above method further includes:

[0215] If a lock record exists and the lock duration corresponding to the lock record is less than or equal to the preset threshold, the system will indicate that the response to the state change request for the first record failed.

[0216] In one embodiment, the above-mentioned status change processing when the third record is not found includes:

[0217] Generate a third record corresponding to the first record mentioned above, and generate a lock record based on the third record;

[0218] Once the above lock record has been generated, the state of the third record will be changed.

[0219] If the above status change is successful, delete the above lock record.

[0220] In one embodiment, the state change processing when a lock record exists and the lock duration corresponding to the lock record exceeds a preset threshold includes:

[0221] Take over the aforementioned lock records and reset the locking time of the aforementioned lock records;

[0222] Once the above lock record has been generated, the state of the third record will be changed.

[0223] If the above status change is successful, delete the above lock record.

[0224] The above are merely preferred embodiments of the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present application should be included within the protection scope of the present application.

Claims

1. A virtual item status management method, characterized by, The method comprises: In the case of receiving a state change request for a first record, determining target period information of the first record, the first record being a management record for recording quantity information of virtual items associated with a target object in a target period; In the case that the target period information represents a first type of period, performing state change on the first record based on a locking interaction mechanism, the first type of period being the minimum time period for generating a management record; In the case that the target period information represents a second type of period, querying all second records associated with the first record, each second record corresponding to a time period within the target period, and each second record corresponding to a period information of the first type, the second type of period including a plurality of the first type of period; In the case that the first record is not associated with any second record, performing state change on the first record based on a locking interaction mechanism; The state change of the first record based on the locking interaction mechanism comprises: Querying a third record, the third record being a record with the same primary key as the first record and having the same target period; In the case that the third record is not queried, performing state change processing; In the case that the third record is queried, querying a lock record corresponding to the third record, the lock record being used to prevent other threads except the takeover thread of the lock record from processing records with the same primary key as the third record; In the case that there is a lock record and the lock time corresponding to the lock record is greater than a preset threshold, performing state change processing.

2. The method of claim 1, wherein, The method further comprises: In the case that all second records associated with the first record are in a first state, performing state change on the first record based on a locking interaction mechanism, only virtual items in management records entered into the database and set to the first state being issued to the corresponding object; The first state represents that the virtual items associated in the corresponding second record have been sent to the target object.

3. The method of claim 2, wherein, The method further comprises: In the case that there is a target second record, prompting that the response of the state change request for the first record fails; Displaying a state change reminder for the target second record, the state change reminder being used to prompt that the state of the target second record is changed to the first state by performing a related operation, or the target second record is deleted; The target second record is a second record not in the first state.

4. The method of claim 3, wherein The state change request is a preview request, the preview request being used to change the first record to a second state, and before determining the target period information of the first record in the case of receiving a state change request for the first record, the method further comprises: Obtaining behavior performance information, the behavior performance information being performance information corresponding to the behavior of the target object in the target period and related to virtual items; According to the first identifier, the second identifier, and the behavior performance information, a first record is generated, the first identifier being an identifier of a virtual item provider corresponding to the target object, and the second identifier being an identifier of a virtual item manager corresponding to the target object; The preview request is generated according to the first record; Or, The state change request is a warehousing request, the warehousing request being used to change the first record to a third state, and before the target time period information of the first record is determined in a case where the state change request for the first record is received, the method further includes: Obtaining behavior performance information, the behavior performance information being performance information corresponding to a virtual item-related behavior of the target object in the target time period; According to the first identifier, the second identifier, and the behavior performance information, a first record is generated, the first identifier being an identifier of a virtual item provider corresponding to the target object, and the second identifier being an identifier of a virtual item manager corresponding to the target object; The warehousing request is generated according to the first record; The state of the management record after the preview request is implemented is referred to as a second state, and the third state is a state in which the management record has been entered into a database but has not yet taken effect.

5. The method of claim 4, wherein, The first record is generated according to the first identifier, the second identifier, and the behavior performance information. The first record is generated according to the first identifier, the second identifier, and the behavior performance information.

6. The method of claim 5, wherein, The method further includes: In a case where the lock record exists and a lock duration corresponding to the lock record is less than or equal to the preset threshold, it is prompted that the response of the state change request for the first record fails.

7. The method of claim 6, wherein, In a case where the third record is not queried, the state change processing is performed, including: The first record is generated, and a lock record is generated based on the first record; In a case where the lock record is generated, the state of the first record is changed to the second state or the third state; In a case where the state change succeeds, the lock record is deleted; The state of the management record after the preview request is implemented is referred to as a second state, and the third state is a state in which the management record has been entered into a database but has not yet taken effect.

8. The method of claim 1 or 6, wherein, In a case where the lock record exists and a lock duration corresponding to the lock record is greater than a preset threshold, the state change processing is performed, including: The lock record is taken over, and the lock time of the lock record is reset; In a case where the lock record is generated, the first record is generated based on the third record, and the state of the first record is changed to the second state or the third state; In a case where the state change succeeds, the lock record is deleted; The state of the management record after the preview request is implemented is referred to as a second state, and the third state is a state in which the management record has been entered into a database but has not yet taken effect.

9. A virtual item status management apparatus characterized by comprising: The apparatus includes: The state change request module is configured to, in response to receiving a state change request for a first record, determine target time period information of the first record, the first record being a management record used to record quantity information of virtual items associated with a target object in a target time period; The state change response module is configured to perform the following operations: In a case where the target time period information represents a first type of time period, performing a state change on the first record based on a locking interaction mechanism, the first type of time period being a minimum time period for generating a management record; In a case where the target time period information represents a second type of time period, querying all second records associated with the first record, each second record corresponding to a time period within the target time period and each second record corresponding to a time period information of the first type of time period, the second type of time period including a plurality of the first type of time period; In a case where the first record is not associated with any second record, performing a state change on the first record based on the locking interaction mechanism; The state change on the first record based on the locking interaction mechanism includes: Querying a third record, the third record being a record having the same primary key as the first record and having the same target time period; In a case where the third record is not queried, performing a state change process; In a case where the third record is queried, querying a lock record corresponding to the third record, the lock record being used to prevent threads other than a takeover thread of the lock record from processing records having the same primary key as the third record; In a case where the lock record exists and a locking duration corresponding to the lock record is greater than a preset threshold, performing a state change process.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores at least one instruction or at least one program, the at least one instruction or at least one program is loaded and executed by the processor to implement the virtual item state management method of any one of claims 1 to 8.

11. An electronic device, comprising: The computer readable storage medium stores at least one instruction or at least one program, the at least one instruction or at least one program is loaded and executed by the processor to implement the virtual item state management method of any one of claims 1 to 8.

12. A computer program product comprising computer programs or instructions, characterized in that, The computer program or instruction is executed by the processor to implement the virtual item state management method of any one of claims 1 to 8.

Images