Event processing method and device, computer readable storage medium, and electronic device

Abstract

The present disclosure belongs to the field of computer technology, and relates to an event processing method and device, a computer-readable storage medium, and an electronic device. The method includes: receiving an event to be processed, and determining whether the thread running the event to be processed is in a transaction; if the thread running the event to be processed is not in a transaction, publishing the event to be processed to execute the event to be processed; if the thread running the event to be processed is in a transaction, storing the event to be processed in a thread local variable queue corresponding to the transaction to submit or roll back the event to be processed. On the one hand, the present disclosure sets a fault-tolerant mechanism to ensure that the program is executed normally when the developer uses the event publisher incorrectly, thereby improving the fault tolerance and robustness of the system; on the other hand, the publishing of events is combined with the thread local variable queue, without the need to seize resources, and the data consistency of the distributed system is guaranteed from the business process, further saving the developer's processing cost for data consistency.

Description

Technical Field

[0001] The present disclosure relates to the field of computer technology, and in particular to an event processing method and device, a computer-readable storage medium, and an electronic device. Background Art

[0002] In a distributed system, communication between the system and external systems is typically embedded directly within the system's transactions, with a retry mechanism added to ensure data consistency. Furthermore, the business logic of distributed transactions using request resources (Try), operation resources (Confirm), and cancellation resources (Cancel) can also achieve consistency in distributed transactions.

[0003] However, embedding external system communications within this system's transactions increases transaction startup time, leading to reduced system throughput and single-transaction timeouts. If an exception occurs within this system's transaction after the external system succeeds, the transaction will roll back, but the external system won't be able to roll back simultaneously, resulting in data inconsistencies across multiple systems. In TCC distributed transactions, writing logic for each of the three phases is highly invasive and expensive, while also reducing system throughput.

[0004] In view of this, there is an urgent need in this field to develop a new event processing method and device.

[0005] It should be noted that the information disclosed in the above background technology section is only used to enhance the understanding of the background of the present disclosure, and therefore may include information that does not constitute prior art known to ordinary technicians in the field. Summary of the Invention

[0006] The purpose of the present disclosure is to provide an event processing method, an event processing device, a computer-readable storage medium and an electronic device, thereby overcoming the problems of data inconsistency and low system throughput caused by the limitations of related technologies to at least a certain extent.

[0007] Other features and advantages of the present disclosure will become apparent from the following detailed description, or may be learned in part by practice of the present disclosure.

[0008] According to a first aspect of an embodiment of the present invention, an event processing method is provided, the method comprising: receiving an event to be processed, and determining whether a thread running the event to be processed is in a transaction; if the thread running the event to be processed is not in a transaction, publishing the event to be processed to execute the event to be processed; if the thread running the event to be processed is in a transaction, storing the event to be processed in a thread local variable queue corresponding to the transaction to commit or roll back the event to be processed.

[0009] In an exemplary embodiment of the present invention, submitting or rolling back the pending event includes: registering a retry record corresponding to the transaction, and simultaneously submitting or rolling back the pending event and the retry record; and clearing the pending event in the thread local variable queue.

[0010] In an exemplary embodiment of the present invention, the simultaneous submission or rollback of the pending event and the retry record includes: registering an event publisher and registering an event publisher in the event publisher; registering the event publisher as an event synchronizer corresponding to the pending event to simultaneously submit or roll back the pending event and the retry record.

[0011] In an exemplary embodiment of the present invention, after committing or rolling back the pending event, the method further includes: obtaining a processing result of the pending event, and modifying the submission status corresponding to the pending event in the retry record according to the processing result; and re-determining whether the thread running the pending event is in a transaction according to the submission status.

[0012] In an exemplary embodiment of the present invention, re-determining whether the thread running the pending event is in a transaction based on the submission status includes: if the submission status is submission failure, obtaining the configuration time corresponding to the retry record, and determining whether the pending event is earlier than the configuration time; if the pending event is not earlier than the configuration time, re-determining whether the thread running the pending event is in a transaction.

[0013] In an exemplary embodiment of the present invention, receiving a pending event and determining whether a thread running the pending event is in a transaction includes: receiving a pending event and creating a thread-local variable queue corresponding to the pending event; when the pending event is a database transaction, modifying a transaction marker variable of the thread-local variable queue; and determining whether the thread running the pending event is in a transaction based on the transaction marker variable.

[0014] In an exemplary embodiment of the present invention, after the pending event is committed or rolled back, the method further comprises: updating a transaction marker variable of the thread-local variable queue.

[0015] According to a second aspect of an embodiment of the present invention, an event processing device is provided, comprising: an event receiving module configured to receive an event to be processed and determine whether a thread running the event to be processed is in a transaction; an event publishing module configured to publish the event to be processed if the thread running the event to be processed is not in a transaction, so as to execute the event to be processed; and an event submission module configured to store the event to be processed in a thread local variable queue corresponding to the transaction if the thread running the event to be processed is in a transaction, so as to submit or roll back the event to be processed.

[0016] According to a third aspect of an embodiment of the present invention, there is provided an electronic device comprising: a processor and a memory; wherein the memory stores computer-readable instructions, which, when executed by the processor, implement the event processing method of any of the above exemplary embodiments.

[0017] According to a fourth aspect of an embodiment of the present invention, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the event processing method in any of the above exemplary embodiments is implemented.

[0018] As can be seen from the above technical solutions, the event processing method, event processing device, computer storage medium, and electronic device in the exemplary embodiments of the present invention have at least the following advantages and positive effects:

[0019] In the method and apparatus provided by the exemplary embodiments of the present disclosure, the function of executing pending events is implemented by setting a fault-tolerance mechanism for threads not in transactions and creating a thread-local variable queue for threads in transactions. On the one hand, setting a fault-tolerance mechanism ensures normal program execution even when developers use event publishers incorrectly, improving the system's fault tolerance and robustness. On the other hand, combining event publishing with a thread-local variable queue eliminates the need for resource preemption, ensuring data consistency in the distributed system from a business process perspective, and further reducing developers' processing costs for data consistency.

[0020] It is to be understood that the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present disclosure, and together with the specification, are used to explain the principles of the present disclosure. Obviously, the drawings described below are only some embodiments of the present disclosure, and those skilled in the art can derive other drawings based on these drawings without inventive effort.

[0022] Figure 1 A flowchart schematically illustrates an event processing method in an exemplary embodiment of the present disclosure;

[0023] Figure 2 A flowchart schematically illustrates a method for determining whether a to-be-processed event is in a transaction in an exemplary embodiment of the present disclosure;

[0024] Figure 3 A flowchart schematically illustrates a method for registering a retry record in an exemplary embodiment of the present disclosure;

[0025] Figure 4 A flowchart schematically illustrates a method for simultaneously processing pending events and retry records in an exemplary embodiment of the present disclosure;

[0026] Figure 5 A flowchart schematically illustrates a processing method after obtaining a processing result in an exemplary embodiment of the present disclosure;

[0027] Figure 6 A flowchart schematically illustrates a method for retrying an event to be processed in an exemplary embodiment of the present disclosure;

[0028] Figure 7 A schematic diagram schematically illustrates a flow chart of an event processing method in an application scenario in an exemplary embodiment of the present disclosure;

[0029] Figure 8 A schematic diagram schematically illustrates the structure of an event processing device in an exemplary embodiment of the present disclosure;

[0030] Figure 9 Schematically illustrates an electronic device for implementing an event processing method in an exemplary embodiment of the present disclosure;

[0031] Figure 10 A computer-readable storage medium for implementing an event processing method in an exemplary embodiment of the present disclosure is schematically shown. DETAILED DESCRIPTION

[0032] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be implemented in a variety of forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that the present disclosure will be more comprehensive and complete and will fully convey the concepts of the example embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, many specific details are provided to provide a full understanding of the embodiments of the present disclosure. However, those skilled in the art will appreciate that the technical solutions of the present disclosure may be practiced while omitting one or more of the specific details, or that other methods, components, devices, steps, etc. may be employed. In other cases, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of the present disclosure.

[0033] The terms "a", "an", "the" and "said" are used in this specification to indicate the presence of one or more elements / components / etc.; the terms "including" and "having" are used to express open-ended inclusion and mean that additional elements / components / etc. may exist in addition to the listed elements / components / etc.; the terms "first" and "second" etc. are used only as labels and are not intended to limit the quantity of their objects.

[0034] In addition, the accompanying drawings are merely schematic illustrations of the present disclosure and are not necessarily drawn to scale. Identical reference numerals in the drawings represent identical or similar parts, and thus repeated descriptions thereof will be omitted. Some of the blocks shown in the accompanying drawings are functional entities and do not necessarily correspond to physically or logically separate entities.

[0035] In response to the problems existing in the related art, the present disclosure proposes an event processing method. Figure 1 A flow chart of an event handling method is shown, such as Figure 1 As shown, the event handling method includes at least the following steps:

[0036] Step S110: Receive an event to be processed, and determine whether the thread running the event to be processed is in a transaction.

[0037] Step S120: If the thread running the pending event is not in a transaction, publish the pending event to execute the pending event.

[0038] Step S130: If the thread running the pending event is in a transaction, the pending event is stored in a thread local variable queue corresponding to the transaction to commit or roll back the pending event.

[0039] In an exemplary embodiment of the present disclosure, the function of executing pending events is implemented by setting a fault-tolerance mechanism for threads not in transactions and creating a thread-local variable queue for threads in transactions. On the one hand, setting a fault-tolerance mechanism ensures normal program execution even when developers use event publishers incorrectly, improving the system's fault tolerance and robustness. On the other hand, combining event publishing with thread-local variable queues eliminates the need for resource preemption, ensuring data consistency in the distributed system from a business process perspective, and further reducing developers' processing costs for data consistency.

[0040] The following is a detailed description of each step of the event handling method.

[0041] In step S110 , an event to be processed is received, and it is determined whether a thread running the event to be processed is in a transaction.

[0042] In the exemplary embodiments of this disclosure, an event, also known as a message, is an object that can be a string returned by a network request or a switch status. A pending event is a broad concept that can be tailored to different business processing requirements and is not limited to a specific event. For example, a pending event could be a document submission, a remittance, or an advertising creative review.

[0043] In an alternative embodiment, Figure 2 A flow chart showing a method for determining whether a pending event is in a transaction is shown in FIG. Figure 2 As shown, the method includes at least the following steps: in step S210, receiving a pending event and creating a thread-local variable queue corresponding to the pending event. After receiving the pending event, a thread-local variable queue is created in the event publisher. The thread-local variable queue is used to temporarily store the pending event. Since different threads running the pending event can use the event publisher in the event publisher, but each thread cannot have a relationship with each other, a thread-local variable queue can be used for storage.

[0044] In step S220, when the pending event is a database transaction, the transaction marker variable of the thread-local variable queue is modified. Since the processing of transactions can ensure that all operations within non-transactional units are completed successfully, otherwise the data-oriented resources will not be permanently updated. By combining a set of related operations into units that are either all successful or all failed, errors can be simplified and the application can be made more reliable. Therefore, transaction processing is used to add, delete, modify and query data in the database to ensure the stability and predictability of database data. A database transaction refers to a series of operations performed as a single logical work unit in the database, which is either completely executed or not executed at all. For example, the submission and review of advertising materials can be database transactions. In addition, other pending events belonging to database transactions can be set according to actual needs, and this exemplary embodiment does not specifically limit this.

[0045] If the pending event is determined to be a database transaction, the transaction marker variable of the thread-local variable queue can be retrieved. This transaction marker variable is a property of the thread-local variable queue. When set to true, it indicates that the pending event is a database transaction; when set to false, it indicates that the pending event is not a database transaction. Therefore, regardless of the previous state of the transaction marker variable, it can be modified to true at this point.

[0046] In step S230, a transaction flag variable is used to determine whether the thread running the pending event is in a transaction. In addition to cases where the pending event is a database transaction, there are also cases where the pending event is not a database transaction. For example, an event such as querying advertising materials may not be a database transaction. Therefore, the transaction flag variable is set to false in this case.

[0047] Whether the transaction marker variable is true or false determines whether the thread running the pending event is in a transaction. When the transaction marker variable is true, it indicates that the pending event is a database transaction, so the thread running the pending event is in a transaction. When the transaction marker variable is false, it indicates that the pending event is not a database transaction, so the thread running the pending event is not in a transaction.

[0048] In this exemplary embodiment, whether the current thread is in a transaction can be determined based on the variables in the created thread local variable queue. The determination method is simple and has high accuracy.

[0049] In step S120 , if the thread running the pending event is not in a transaction, the pending event is published to execute the pending event.

[0050] In an exemplary embodiment of the present disclosure, when the transaction marker variable in the thread-local variable queue is false, it can be determined that the thread executing the pending event is not in a transaction. In this case, the present disclosure provides a fault-tolerance mechanism that can publish pending events through a normal event publisher in the event publisher, ensuring the normal operation of the program and improving the fault tolerance and robustness of the event processing system.

[0051] In step S130 , if the thread running the pending event is in a transaction, the pending event is stored in a thread local variable queue corresponding to the transaction to commit or roll back the pending event.

[0052] In an exemplary embodiment of the present disclosure, when the transaction flag variable of the thread-local variable queue is true, it can be determined that the thread running the pending event is in a transaction. In this case, the pending event can be stored in the previously created thread-local variable queue to execute the pending event.

[0053] In an alternative embodiment, Figure 3 A flow chart showing a method for registering a retry record is shown in FIG. Figure 3 As shown, the method includes at least the following steps: in step S310, registering a retry record corresponding to the transaction, and simultaneously committing or rolling back the pending event and the retry record. The retry record can be registered when the pending event is a transaction and stored in a database. The retry record can record information related to the pending event, such as the processing result of the pending event and the processing event. Therefore, the pending event and the retry record can be committed or rolled back simultaneously.

[0054] In an alternative embodiment, Figure 4 A flow chart showing a method for simultaneously processing pending events and retrying records is shown, as shown in FIG. Figure 4 As shown, the method includes at least the following steps: in step S410, register an event publisher, and register an event publisher in the event publisher. The publishing process of the event publisher depends on an originally ordinary event being published on the event bus. Among them, the event publisher is an implementation of the publish-subscribe model, which is a centralized event processing mechanism that allows different components to communicate with each other without relying on each other, achieving a decoupling purpose; the event publisher can be an object that publishes an event, and publishes the event through the interface that publishes the event. Registering the event publisher with the event publisher is to let the event publisher hold an ordinary event publisher as a member variable.

[0055] In step S420, the event publisher is registered as an event synchronizer corresponding to the pending event, so that the pending event and retry records can be submitted or rolled back simultaneously. After registering the event publisher, it can also be registered as an event synchronizer in the transaction manager, which receives messages and performs corresponding logic after the transaction is committed or rolled back. Therefore, after registering the event synchronizer, the pending event and retry records can be submitted or rolled back simultaneously according to the logic of the pending event.

[0056] In this exemplary embodiment, the registered event publisher also serves as an event synchronizer to ensure data consistency from a business process perspective.

[0057] In step S320, the pending events in the thread local variable queue are cleared. If the execution process of the pending event is normal, a submission operation is performed; if an exception occurs in the execution process of the pending event, a rollback operation is performed. After the pending event is submitted, the event manager triggers the event synchronizer to publish the pending event in the thread local variable queue in the event publisher to the event bus via a common event publisher, and the subscriber in the event bus executes the subscriber's logic synchronously or asynchronously. Among them, the event subscriber depends on the connection between the event bus and the event publisher, and is an object that subscribes to a certain type of event. When an event publisher publishes such an event, the event bus executes the event processing function of the time subscriber to execute the logic therein. In addition, the pending events in the thread local variable queue are cleared to restore it to its initial state. If the pending event is rolled back, the pending events in the thread local variable queue are also cleared, and the thread local variable queue is restored to its initial state.

[0058] In this exemplary embodiment, the manner of processing pending events and thread local variable queues after registering the retry record can maintain the storage performance of the thread local variable queue and ensure the realization of data consistency.

[0059] In addition, after the pending event is committed or rolled back, the transaction marker variable of the thread local variable queue can be modified to facilitate the judgment and execution of the next pending event.

[0060] In an optional embodiment, the transaction marker variable of the thread-local variable is updated. Specifically, after the event subscriber in the event bus completes the execution of the event subscriber's logic synchronously or asynchronously, the transaction marker variable can be changed from true to false. If the transaction is rolled back, the transaction marker variable is also changed to false to restore the initial state.

[0061] After the pending event is submitted, there may be an exception that the pending event fails to execute or is not executed. Therefore, subsequent processing can still be performed.

[0062] In an alternative embodiment, Figure 5 A flow chart of the processing method after obtaining the processing result is shown in FIG. Figure 5 As shown, the method includes at least the following steps: In step S510, the processing result of the pending event is obtained, and the submission status corresponding to the pending event in the retry record is modified according to the processing result. If the pending event is submitted normally, the submission status corresponding to the pending event in the retry record can be modified to completed; if the pending event is rolled back, the submission status corresponding to the pending event in the retry record can be modified to submission failure or incomplete, and the modification is made according to the actual setting.

[0063] In step S520, it is determined whether the thread running the pending event is in a transaction based on the commit status. If the commit status is completed, it indicates that the pending event has been completed; if the commit status is incomplete or failed, it indicates that the pending event was not successfully executed and a retry operation can be performed.

[0064] In an alternative embodiment, Figure 6 A flow chart showing a method for retrying pending events is shown in FIG. Figure 6 As shown, the method at least includes the following steps: in step S610, if the submission status is submission failure, obtain the configuration time corresponding to the retry record, and determine whether the pending event is earlier than the configuration time. When the submission status of the pending event is submission failure, it indicates that a retry operation is required, and the configuration time set by the retry record can be further obtained. The configuration time can be the retry frequency configured for the pending event, which can be set to 1 minute, 3 minutes, or other durations. This exemplary embodiment does not make special restrictions on this. Since the submission time of the pending event is recorded in the retry record, it can be judged whether the pending event is executed earlier than the configuration time based on the comparison result of the submission time and the configuration time.

[0065] In step S620, if the pending event is not executed earlier than the configured time, it is re-determined whether the thread running the pending event is in a transaction. If the configured time is 3 minutes, and the pending event is executed at 2 minutes, it can be determined that the pending event is executed later than the configured time. Therefore, the time subscriber can re-determine whether the thread running the pending event is in a transaction and perform a second round of loop execution until the execution is successful. Only then can the retry status of the pending event be changed to completed. If the execution is not successful, the error count can be increased and the next retry operation can be performed.

[0066] In this exemplary embodiment, the retry operation of the pending event can be initiated by the retry record, thereby ensuring the eventual consistency of the data in the pending event.

[0067] The event processing method in the embodiment of the present disclosure is described in detail below with reference to an application scenario.

[0068] Figure 7 A flow chart of an event processing method in an application scenario is shown, such as Figure 7 As shown, in step S710, when a pending event for reviewing advertising materials is submitted, since the reviewing advertising materials is a database transaction, the transaction flag variable of the created thread local variable queue can be modified to true for subsequent judgment.

[0069] In step S711, the event publisher related to the review of the advertising material is registered as an event synchronizer in the code container to ensure that the message can be received when the subsequent transaction is committed or rolled back.

[0070] In step S712, when the event publisher is used to publish an event, it may be further determined whether the thread running the advertising material review is in a transaction.

[0071] In step S713, if the thread running the review of the advertising material is in a transaction, the review of the advertising material is stored in the thread local variable queue.

[0072] In step S714, a retry record corresponding to the audited advertising material is registered and stored in a database.

[0073] In step S715 , the logic in the transaction corresponding to reviewing the advertising material is determined.

[0074] In step S716 , the event publisher publishes the audit advertisement material in the thread local variable queue in the event publisher to the event bus, and the event subscriber in the event bus executes the logic of the event subscriber synchronously or asynchronously.

[0075] In step S717, after the logic of the advertising material review is executed, the event of the advertising material review can be retrieved from the thread local variable queue.

[0076] In step S718 , the event execution of the advertising material review is abnormal, and the event is rolled back.

[0077] In step S719 , the advertising material review events in the thread local variable queue are cleared.

[0078] In step S720 , the transaction marker variable of the thread local variable is updated and the transaction marker variable is modified to false.

[0079] In step S721, if the event submitted initially is a pending event for querying advertising materials, it can be determined whether the thread running the query advertising materials is in a transaction and the result is no, and the time of querying advertising materials is directly sent to the event publisher for event publishing.

[0080] In step S722 , the event subscriber receives the submitted or published advertising creative review event or advertising creative query event via the event bus.

[0081] In step S723 , when the event submission is successful, the event subscriber modifies the retry status of the creative review event in the retry record to completed.

[0082] In step S724, when the event submission fails, the event subscriber can obtain a retry record.

[0083] In step S725 , the configuration time corresponding to the retry record is obtained, and it is determined whether the advertising material review event is earlier than the configuration time.

[0084] In step S726 , when the advertising material review event is later than the configured time, the event subscriber may re-determine whether the thread running the advertising material review event is in a transaction and perform the next round of processing.

[0085] In step S727, it is determined whether the new round of event processing is successful.

[0086] In step S728 , when the advertising creative review event succeeds in the second round of processing, the event subscriber modifies the retry status in the retry record to completed.

[0087] In step S729 , when the advertising material review event fails in the second round of processing, the error count may be increased and the process may wait for another retry.

[0088] In an exemplary embodiment of the present disclosure, the function of executing pending events is implemented by setting a fault-tolerance mechanism for threads not in transactions and creating a thread-local variable queue for threads in transactions. On the one hand, setting a fault-tolerance mechanism ensures normal program execution even when developers use event publishers incorrectly, improving the system's fault tolerance and robustness. On the other hand, combining event publishing with thread-local variable queues eliminates the need for resource preemption, ensuring data consistency in the distributed system from a business process perspective, and further reducing developers' processing costs for data consistency.

[0089] In addition, in an exemplary embodiment of the present disclosure, an event processing device is also provided. Figure 8 A schematic diagram of the structure of the event processing device is shown in FIG. Figure 8As shown, the event processing device 800 may include: an event receiving module 810, an event publishing module 820, and an event submitting module 830. Among them:

[0090] The event receiving module 810 is configured to receive pending events and determine whether the thread running the pending event is in a transaction; the event publishing module 820 is configured to publish the pending event if the thread running the pending event is not in a transaction to execute the pending event; the event submission module 830 is configured to store the pending event in the thread local variable queue corresponding to the transaction if the thread running the pending event is in a transaction to submit or roll back the pending event.

[0091] The specific details of the above-mentioned event processing device 800 have been described in detail in the corresponding event processing method, so they will not be repeated here.

[0092] It should be noted that although several modules or units of the event processing device 800 are mentioned in the detailed description above, such division is not mandatory. In fact, according to the embodiment of the present disclosure, the features and functions of two or more modules or units described above can be concretized in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided into multiple modules or units to be concretized.

[0093] In addition, in an exemplary embodiment of the present disclosure, an electronic device capable of implementing the above method is also provided.

[0094] Refer to the following Figure 9 An electronic device 900 according to such an embodiment of the present invention will be described. Figure 9 The electronic device 900 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present invention.

[0095] like Figure 9 As shown, electronic device 900 is implemented as a general-purpose computing device. Components of electronic device 900 may include, but are not limited to, the at least one processing unit 910 described above, the at least one storage unit 920 described above, a bus 930 connecting various system components (including storage unit 920 and processing unit 910), and a display unit 940.

[0096] The storage unit stores program codes, which can be executed by the processing unit 910, so that the processing unit 910 performs the steps according to various exemplary embodiments of the present invention described in the above “Exemplary Methods” section of this specification.

[0097] The storage unit 920 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 921 and / or a cache memory unit 922 , and may further include a read-only memory unit (ROM) 923 .

[0098] The storage unit 920 may also include a program / utility 924 having a set (at least one) of program modules 925, such program modules 925 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment.

[0099] Bus 930 may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.

[0100] The electronic device 900 can also communicate with one or more external devices 1100 (e.g., a keyboard, a pointing device, a Bluetooth device, etc.), one or more devices that enable a user to interact with the electronic device 900, and / or any device that enables the electronic device 900 to communicate with one or more other computing devices (e.g., a router, a modem, etc.). Such communication can occur via an input / output (I / O) interface 950. Furthermore, the electronic device 900 can communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network such as the Internet) via a network adapter 960. As shown, the network adapter 940 communicates with other modules of the electronic device 900 via a bus 930. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the electronic device 900, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0101] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the example embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.

[0102] In exemplary embodiments of the present disclosure, a computer-readable storage medium is also provided, storing a program product capable of implementing the aforementioned methods of this specification. In some possible embodiments, various aspects of the present invention may also be implemented in the form of a program product comprising program code. When the program product is executed on a terminal device, the program code is configured to cause the terminal device to perform the steps according to various exemplary embodiments of the present invention described in the "Exemplary Methods" section of this specification.

[0103] refer to Figure 10 As shown, a program product 1000 for implementing the above method according to an embodiment of the present invention is described. The program product 1000 may be a portable compact disc read-only memory (CD-ROM) and include program code, and may be run on a terminal device, such as a personal computer. However, the program product of the present invention is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0104] The program product may be implemented in any combination of one or more readable media. The readable medium may be a readable signal medium or a readable storage medium. The readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.

[0105] A computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries readable program code. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0106] The program code embodied on the readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0107] The program code for performing the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, and the like, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user computing device, partially on the user device, as a stand-alone software package, partially on the user computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving a remote computing device, the remote computing device may be connected to the user computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0108] Other embodiments of the present disclosure will readily occur to those skilled in the art after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present disclosure that follow from the general principles of the present disclosure and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the present disclosure being indicated by the claims.

Claims

1. An event processing method, characterized in that: The method comprises: Receive a pending event, and determine whether a thread running the pending event is in a transaction; If the thread running the pending event is not in a transaction, publishing the pending event to execute the pending event; If the thread running the pending event is in a transaction, the pending event is stored in a thread local variable queue corresponding to the transaction to commit or roll back the pending event; Wherein, submitting or rolling back the pending event includes: Registering a retry record corresponding to the transaction, registering an event publisher, and registering an event publisher in the event publisher; registering the event publisher as an event synchronizer corresponding to the pending event to simultaneously commit or roll back the pending event and the retry record; Clear the pending events in the thread local variable queue.

2. The event processing method according to claim 1, characterized in that: After submitting or rolling back the pending event, the method further includes: Obtaining a processing result of the event to be processed, and modifying a submission status corresponding to the event to be processed in the retry record according to the processing result; Re-determine whether the thread running the event to be processed is in a transaction according to the submission status.

3. The event processing method according to claim 2, characterized in that: The re-determining whether the thread running the event to be processed is in a transaction according to the submission status includes: If the submission status is submission failure, obtain the configuration time corresponding to the retry record, and determine whether the event to be processed is earlier than the configuration time; If the event to be processed is not earlier than the configured time, it is re-determined whether the thread running the event to be processed is in a transaction.

4. The event processing method according to claim 1, characterized in that: The receiving of the pending event and determining whether the thread running the pending event is in a transaction includes: Receive an event to be processed, and create a thread local variable queue corresponding to the event to be processed; When the event to be processed is a database transaction, modifying the transaction marker variable of the thread local variable queue; It is determined whether the thread running the event to be processed is in a transaction according to the transaction mark variable.

5. The event processing method according to claim 4, characterized in that: After submitting or rolling back the pending event, the method further includes: The transaction marker variable of the thread local variable queue is updated.

6. An event processing device, characterized in that: include: An event receiving module is configured to receive an event to be processed and determine whether a thread running the event to be processed is in a transaction; An event publishing module is configured to publish the event to be processed if the thread running the event to be processed is not in a transaction, so as to execute the event to be processed; An event submission module is configured to store the event to be processed in a thread local variable queue corresponding to the transaction if the thread running the event to be processed is in a transaction, so as to submit or roll back the event to be processed; Wherein, submitting or rolling back the pending event includes: Register a retry record corresponding to the transaction, register an event publisher, and register an event publisher in the event publisher; register the event publisher as an event synchronizer corresponding to the pending event to simultaneously commit or roll back the pending event and the retry record; clear the pending event in the thread local variable queue.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the event processing method described in any one of claims 1 to 5 is implemented.

8. An electronic device, characterized in that: include: processor; A memory, configured to store executable instructions of the processor; The processor is configured to execute the event processing method described in any one of claims 1 to 5 by executing the executable instructions.

Images