CN113722330A - Method and device for retrying online transaction failure - Google Patents

Abstract

The invention relates to the technical field of online transaction failure retry, and discloses an online transaction failure retry device which comprises a failure retry transaction identification module, a transaction layer configuration retry error code and a peripheral system layer configuration retry error code. The invention sets the identification module of the failure retry transaction, the retry error code of the transaction layer configuration and the retry error code of the peripheral system layer configuration, can realize the unified control, centralized management and flexible configuration of the server of the identification logic of the failure retry, meanwhile, the invention can accurately associate the original transaction and the retry transaction based on the transaction power and the like, and realize the management and control of the retry transaction.

Description

Method and device for retrying online transaction failure

Technical Field

The invention relates to the technical field of online transaction failure retry, in particular to an online transaction failure retry method and device.

Background

When an online transaction processing system processes a request, transaction processing may fail due to various reasons (including business layer reasons and system layer reasons), for example, a normal transfer transaction may fail due to network jitter between an application server and a database server, may fail due to lock conflicts in an account table in a database, or may fail due to insufficient account balance.

From an idempotent perspective, the results of multiple retries for a transaction that is completed (whether the state is a process success or a process failure) must be consistent with the first-time process results; theoretically, this is really a better solution; however, in practical application scenarios, analysis of error reasons of failed transactions is required, and for some specific error reasons, the online transaction processing system needs to support retry of failed transactions.

The transaction idempotent is an excellent theoretical model and a solution, and the transaction retry is a supplement and enrichment to the transaction idempotent in the actual application scene; the two are not opposite but form a complete system together; in the process of transaction retry, the principle of transaction idempotent is still adhered to; for example, for a certain failed transaction meeting the retry condition, the retry request and the original request must also satisfy the idempotent principle (transaction flow number idempotent, request message idempotent, scene customization idempotent, etc.).

Preconditions for transaction retry: first, only for failed common transactions (non-hedge transactions, non-verification transactions), this mainly accounts for the transaction type of transaction retry; secondly, the error reason must meet the retry requirement, which mainly explains the transaction retry scenario; thirdly, the retry transaction request and the original transaction request must accord with the principle of idempotent transaction, which mainly realizes the precise control of transaction implementation.

In the prior art, the transaction serial number can be replaced by the client to support the function of retrying the failed transaction. After the online transaction processing fails, the client identifies a retry scene according to the error code in the return message, and initiates retry by the reused new transaction serial number.

In the prior art, the client mainly controls the main logic of the failed retry transaction, which results in that the identification decision logic of the failed retry transaction is relatively dispersed (peripheral systems using the function need to be respectively realized), and the centralized and unified control of the server is lost; or the client uses the new transaction flow to resend the transaction, the server can process the transaction as a new transaction, the management and control of the server on the transaction can be avoided, and the association relationship between the original transaction and the retry transaction cannot be managed and controlled.

Disclosure of Invention

The present invention is directed to a method and apparatus for retry of online transaction failure, so as to solve the above problems in the prior art.

In order to achieve the purpose, the invention provides the following technical scheme:

an online transaction failure retry device comprises a failure retry transaction identification module, a transaction layer configuration retriable error code and a peripheral system layer configuration retriable error code, wherein the failure retry transaction identification module comprises a transaction configuration table, a transaction registration table, a transaction retry check table and a transaction idempotent check table, the transaction configuration table comprises a default retriable error code list, a default maximum retry number and a default minimum retry interval, and the transaction registration table comprises a retriable error code list, a maximum retry number and a minimum retry interval, wherein the transaction layer is a system layer, and the peripheral system layer is a channel layer.

As a still further scheme of the invention: the default retry-approved error code list is used for accurately controlling which error codes of the transaction can be retried, the default retry-approved error code list is the default control of a transaction layer, and the default retry-approved error code list is effective when the control of a peripheral system layer is null; the default maximum retry number is used for controlling the maximum retry number of the failure retry, and infinite failure retry is avoided; the default minimum retry interval is used to control the period and frequency of failed retries to avoid retries being too frequent.

As a still further scheme of the invention: the transaction registry is used for realizing the failure retry control of a peripheral system layer, and the priority of control logic of the peripheral system layer (channel layer) is higher than that of a transaction layer (system layer); the relationship between the peripheral system layer control logic and the transaction layer control logic is an alternative relationship, and the peripheral system layer control logic and the transaction layer control logic cannot be simultaneously effective, namely, for a control point of a determined transaction retry failure, the peripheral system layer is effective, or the transaction layer is effective, but the peripheral system layer and the transaction layer cannot be simultaneously effective.

As a still further scheme of the invention: the transaction retry check table is used for recording relevant data of failed retry transactions.

A method for retry of online transaction failure comprises decision logic of retry failure and execution logic of retry failure, wherein the decision logic of retry failure comprises operations of a transaction configuration table, a transaction registry and a transaction retry check table, and the operation flow comprises the following steps:

s11, when the online transaction starts, the logic of transaction idempotent is executed first, and then the precondition of failure retry is checked: the original transaction is a common transaction, the state of the original transaction is 'processing failure', the original transaction request and the current request are idempotent, and the like, wherein the common transaction is a non-conflict orthogonal transaction, a non-verification transaction, and if the state of the original transaction is not satisfied, the transaction returns 'retry incapable';

s12, inquiring the transaction registry according to the transaction code and the peripheral system ID, and obtaining the relevant control parameters of the peripheral system layer, including: a retry-able error code list, a maximum number of retries, and a minimum retry interval;

s13, inquiring the transaction configuration table according to the transaction code, and acquiring the relevant control parameters of the transaction layer, including: a default retriable error code list, a default maximum retry number, a default minimum retry interval;

s14, determining an error code: checking whether a 'retry error code list' of a peripheral system layer is empty, if so, detecting whether a current transaction error code is in the retry error code list by using a 'default retry error code list' of a transaction layer; if not, using a peripheral system layer 'retry error code list' to detect;

the judgment and detection results are as follows: if the current transaction error code is not contained in the list, the transaction is not retried, and the condition of 'retry incapability' is returned, otherwise, further judgment is needed;

s15, inquiring a transaction retry detection table according to the transaction serial number, acquiring retry times and last retry time, and if the retry times and the last retry time cannot be found, defaulting to be null;

s16, determining the number of retries: judging whether the maximum retry number of the peripheral system layer is null or not; if yes, comparing the default maximum retry number of the transaction layer with the retried number for judgment; if not, comparing the maximum retry number of the peripheral system layer with the retry number for judgment; if the retry time > = retry time threshold, returning to not retry, otherwise, needing further judgment;

s17, determining a retry interval: judging whether the minimum retry interval of the peripheral system layer is empty or not; if yes, comparing and judging the default minimum retry interval of the transaction layer with the last retry time and the current time; if not, comparing the minimum retry interval of the peripheral system layer with the last retry time and the current time for judgment; if the last retry time + retry interval threshold > = current time, returning to 'retry not possible'; otherwise, "retry capable" is returned.

As a still further scheme of the invention: the execution logic of the failed retry comprises the operation of a transaction idempotent check table and a transaction retry check table, and the operation flow comprises the following steps:

s21, updating the transaction state of the transaction idempotent check table according to the transaction serial number by using independent transactions, and changing from 'failure in transaction processing' to 'in transaction processing';

s22, if the operation fails, it shows that there is a retry request of concurrent processing, and returns to "retry in original transaction"; if the operation is successful, entering a normal business logic processing flow;

s23, after the normal service logic processing flow is completed, a transaction retry check list needs to be registered;

s24, if the first registration, assigning values for all the fields, and executing insertion operation;

and S25, if not, assigning values to two fields of retried times and last retry time, and executing updating operation.

Compared with the prior art, the invention has the beneficial effects that:

the invention sets the identification module of the failure retry transaction, the retry error code of the transaction layer configuration and the retry error code of the peripheral system layer configuration, can realize the unified control, centralized management and flexible configuration of the server of the identification logic of the failure retry, meanwhile, the invention can accurately associate the original transaction and the retry transaction based on the transaction power and the like, and realize the management and control of the retry transaction.

Drawings

FIG. 1 is a schematic diagram of a transaction configuration table for retry of transaction failure in a method for retry of online transaction failure;

FIG. 2 is a schematic diagram of a transaction registry of transaction failure retries in a method of online transaction failure retries;

FIG. 3 is a diagram of a transaction retry check table for transaction failure retries in an online transaction retry method;

FIG. 4 is a diagram of an idempotent look-up table for an online retry method for failed transactions;

FIG. 5 is a logic flow diagram illustrating a transaction failure retry decision in a method for online transaction failure retry;

FIG. 6 is a logic flow diagram illustrating execution of retry of transaction failure in a method for retry of online transaction failure.

Detailed Description

In an embodiment of the present invention, an apparatus for retry of online transaction failure includes a transaction identification module for retry failure, a transaction layer configuration retriable error code, and a peripheral system layer configuration retriable error code, where the transaction identification module for retry failure includes a transaction configuration table, a transaction registration table, a transaction retry check table, and a transaction idempotent check table, the transaction configuration table includes a default retriable error code list, a default maximum retry number, and a default minimum retry interval, and the transaction registration table includes a retriable error code list, a maximum retry number, and a minimum retry interval, where the transaction layer is a system layer, and the peripheral system layer is a channel layer.

Preferably, the default retriable error code list is used for precisely controlling which error codes of the transaction can be retried, the default retriable error code list is the default control of the transaction layer, and the default retriable error code list is effective when the control of the peripheral system layer is null; the default maximum retry number is used for controlling the maximum retry number of the failure retry, and infinite failure retry is avoided; the default minimum retry interval is used to control the period and frequency of failed retries to avoid retries being too frequent.

Preferably, the transaction registry is used for implementing failure retry control of a peripheral system layer, and the priority of the control logic of the peripheral system layer (channel layer) is higher than that of the transaction layer (system layer); the relationship between the peripheral system layer control logic and the transaction layer control logic is an alternative relationship, and the peripheral system layer control logic and the transaction layer control logic cannot be simultaneously effective, namely, for a control point of a determined transaction retry failure, the peripheral system layer is effective, or the transaction layer is effective, but the peripheral system layer and the transaction layer cannot be simultaneously effective.

Preferably, the transaction retry check table is used for recording data related to failed retry transactions.

In fig. 5, the operation flow includes the following steps:

s11, at 101, when the online transaction starts, the idempotent logic is executed first, and then the precondition of failed retry is checked: the original transaction is a common transaction, the state of the original transaction is 'processing failure', the original transaction request and the current request are idempotent, and the like, wherein the common transaction is a non-conflict orthogonal transaction, a non-verification transaction, and if the state of the original transaction is not satisfied, the transaction returns 'retry incapable';

s12, in 102, inquiring the transaction registry according to the transaction code and the peripheral system ID to obtain the relevant control parameters of the peripheral system layer, including: a retry-able error code list, a maximum number of retries, and a minimum retry interval;

s13, in 103, querying the transaction configuration table according to the transaction code to obtain the relevant control parameters of the transaction layer, including: a default retriable error code list, a default maximum retry number, a default minimum retry interval;

s14, at 104 — make a decision on the error code: checking whether a 'retry error code list' of a peripheral system layer is empty, if so, detecting whether a current transaction error code is in the retry error code list by using a 'default retry error code list' of a transaction layer; if not, using a peripheral system layer 'retry error code list' to detect;

the judgment and detection results are as follows: if the current transaction error code is not contained in the list, the transaction is not retried, and the condition of 'retry incapability' is returned, otherwise, further judgment is needed;

s15, in 105, inquiring a transaction retry detection table according to the transaction serial number to obtain the retry times and the last retry time, and if the retry times and the last retry time cannot be found, the default is null;

s16, at 106 — determine for the number of retries: judging whether the maximum retry number of the peripheral system layer is null or not; if yes, comparing the default maximum retry number of the transaction layer with the retried number for judgment; if not, comparing the maximum retry number of the peripheral system layer with the retry number for judgment; if the retry time > = retry time threshold, returning to not retry, otherwise, needing further judgment;

s17, at 107-making a decision for the retry interval: judging whether the minimum retry interval of the peripheral system layer is empty or not; if yes, comparing and judging the default minimum retry interval of the transaction layer with the last retry time and the current time; if not, comparing the minimum retry interval of the peripheral system layer with the last retry time and the current time for judgment; if the last retry time + retry interval threshold > = current time, returning to 'retry not possible'; otherwise, "retry capable" is returned.

As a still further scheme of the invention: the execution logic of the failed retry comprises the operation of a transaction idempotent check table and a transaction retry check table, and in fig. 6, the operation flow comprises the following steps:

s21, in 201, updating the transaction state of the transaction idempotent checking table according to the transaction serial number by using independent transaction, and changing from 'failure in transaction processing' to 'in transaction processing';

s22, at 202-if the operation fails, it indicates that there is a retry request for concurrent processing, and returns to "retry in original transaction"; if the operation is successful, entering a normal business logic processing flow;

s23, in 203-after the normal business logic processing flow is completed, the transaction retry check list needs to be registered;

s24, at 204 — if it is first registered, assign values to all fields, perform insert operation;

s25, at 205-if not the first registration, then the update operation is performed by assigning values to the two fields of the number of retries and the time of the last retry. .

The above description is only for the preferred embodiment of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art should be considered to be within the technical scope of the present invention, and the technical solutions and the inventive concepts thereof according to the present invention are equivalent to or changed within the technical scope of the present invention.

Claims (6)

1. An on-line transaction failure retry device comprises a failure retry transaction identification module, a transaction layer configuration retriable error code and a peripheral system layer configuration retriable error code, wherein the failure retry transaction identification module comprises a transaction configuration table, a transaction registration table, a transaction retry check table and a transaction idempotent check table, the transaction configuration table comprises a default retriable error code list, a default maximum retry number and a default minimum retry interval, and the transaction registration table comprises a retriable error code list, a maximum retry number and a minimum retry interval, wherein the transaction layer is a system layer, and the peripheral system layer is a channel layer.

2. The apparatus of claim 1, wherein the default retry-approved error code list is used to precisely control which error codes of the transaction can be retried, and the default retry-able error code list is a default control of the transaction layer, and the default retry-able error code list is valid when the control of the peripheral system layer is null; the default maximum retry number is used for controlling the maximum retry number of the failure retry, and infinite failure retry is avoided; the default minimum retry interval is used to control the period and frequency of failed retries to avoid retries being too frequent.

3. The apparatus of claim 1, wherein the transaction registry is configured to implement peripheral system level retry control, wherein the peripheral system level (channel level) control logic has a higher priority than the transaction level (system level); the relationship between the peripheral system layer control logic and the transaction layer control logic is an alternative relationship, and the peripheral system layer control logic and the transaction layer control logic cannot be simultaneously effective, namely, for a control point of a determined transaction retry failure, the peripheral system layer is effective, or the transaction layer is effective, but the peripheral system layer and the transaction layer cannot be simultaneously effective.

4. The apparatus of claim 1, wherein the transaction retry check table is used to record data related to the failed retry transaction.

5. A method for implementing the online transaction failure retry of claim 1, which is composed of a determination logic of failure retry and an execution logic of failure retry, wherein the determination logic of failure retry comprises operations of a transaction configuration table, a transaction registry table and a transaction retry check table, and the operation flow comprises the following steps:

s11, when the online transaction starts, the logic of transaction idempotent is executed first, and then the precondition of failure retry is checked: the original transaction is a common transaction, the state of the original transaction is 'processing failure', the original transaction request and the current request are idempotent, and the like, wherein the common transaction is a non-conflict orthogonal transaction, a non-verification transaction, and if the state of the original transaction is not satisfied, the transaction returns 'retry incapable';

s12, inquiring the transaction registry according to the transaction code and the peripheral system ID, and obtaining the relevant control parameters of the peripheral system layer, including: a retry-able error code list, a maximum number of retries, and a minimum retry interval;

s13, inquiring the transaction configuration table according to the transaction code, and acquiring the relevant control parameters of the transaction layer, including: a default retriable error code list, a default maximum retry number, a default minimum retry interval;

s14, determining an error code: checking whether a 'retry error code list' of a peripheral system layer is empty, if so, detecting whether a current transaction error code is in the retry error code list by using a 'default retry error code list' of a transaction layer; if not, using a peripheral system layer 'retry error code list' to detect;

the judgment and detection results are as follows: if the current transaction error code is not contained in the list, the transaction is not retried, and the condition of 'retry incapability' is returned, otherwise, further judgment is needed;

s15, inquiring a transaction retry detection table according to the transaction serial number, acquiring retry times and last retry time, and if the retry times and the last retry time cannot be found, defaulting to be null;

s16, determining the number of retries: judging whether the maximum retry number of the peripheral system layer is null or not; if yes, comparing the default maximum retry number of the transaction layer with the retried number for judgment; if not, comparing the maximum retry number of the peripheral system layer with the retry number for judgment; if the retry time > = retry time threshold, returning to not retry, otherwise, needing further judgment;

s17, determining a retry interval: judging whether the minimum retry interval of the peripheral system layer is empty or not; if yes, comparing and judging the default minimum retry interval of the transaction layer with the last retry time and the current time; if not, comparing the minimum retry interval of the peripheral system layer with the last retry time and the current time for judgment; if the last retry time + retry interval threshold > = current time, returning to 'retry not possible'; otherwise, "retry capable" is returned.

6. The method of claim 5, wherein the execution logic of the failed retry comprises the operations of the transaction idempotent check table and the transaction retry check table, and the operation flow comprises the following steps:

s21, updating the transaction state of the transaction idempotent check table according to the transaction serial number by using independent transactions, and changing from 'failure in transaction processing' to 'in transaction processing';

s22, if the operation fails, it shows that there is a retry request of concurrent processing, and returns to "retry in original transaction"; if the operation is successful, entering a normal business logic processing flow;

s23, after the normal service logic processing flow is completed, a transaction retry check list needs to be registered;

s24, if the first registration, assigning values for all the fields, and executing insertion operation;

and S25, if not, assigning values to two fields of retried times and last retry time, and executing updating operation.

Images