Concurrent data processing and electronic bookkeeping

Concurrent processing of business transaction data uses a time slice-centered scheme to cope with the situation where multiple requests demand a same resource at the same time. The method divides the processing time into multiple time slices, allocates each request to a corresponding time slice, and iteratively processing requests according to their corresponding time slices. The method does not require the requests to be processed one by one, and therefore does not cause a situation where other requests have to wait until the current request has been completely processed. Moreover, if a certain time slice has been allocated multiple requests of a same type, the requests are collectively processed as if they were a single request to reduce the frequencies of resource locking and unlocking, as well as the waiting time in a queue for resource access.

RELATED APPLICATIONS

This application is a national stage application of international patent application PCT/US09/51481 filed Jul. 23, 2009, entitled “CONCURRENT DATA PROCESSING AND ELECTRONIC BOOKKEEPING” which claims priority from Chinese patent application, Application No. 200810134773.3, filed Jul. 29, 2008, entitled “CONCURRENT DATA PROCESSING METHOD AND APPARATUS, AND ELECTRONIC BOOKKEEPING SYSTEM”, which applications are hereby incorporated in their entirety by reference.

TECHNICAL FIELD

The present disclosure relates to data processing technologies, and particularly relates to methods and apparatuses for concurrent data processing, and electronic bookkeeping systems.

BACKGROUND

Concurrent processing is a common processing method in various business application systems. For example, highly concurrent transactions in a financial system, such as account processing, involve bookkeeping of payments made from one account to multiple accounts at the same time, or payments collected from multiple accounts to a single account at the same time.

In a typical bookkeeping process in trading, resource locks are first placed on accounts related to the trading (which may include a payment account of a buyer and a recipient account of a seller) to ensure that accuracy of data is not affected by other requests. Bookkeeping of the buyer's account, including voucher recording and balance update, is then performed, and followed by bookkeeping of the seller's account which also includes voucher recording and balance update. After the event of bookkeeping request is completely processed, the resource locks on the buyer's account and the seller's account are both released.

Generally, relevant accounts are required to be locked in each bookkeeping operation in order to avoid other operations from further operating on a currently processed account to cause data inconsistency. As volume of business continues to increase, certain accounts may have multiple concurrent operations in an instant period of time. However, only one thread out of all concurrency threads can possess a resource lock at a time, while other threads are required to wait until the lock is released to conduct bookkeeping accordingly. Under these circumstances, performance of a billing system is severely affected.

For example, if a thousand lottery players make payments to a lottery account at the same time, the events would cause approximately a thousand requests in a queue of the lottery account at that moment. If every request has to wait for its turn to obtain a locking right to be processed, business may be severely affected.

The problem of multiple requests demanding to occupy a same resource at the same time also exists in concurrent processing of other business systems to greatly affect the business efficiency.

SUMMARY

The present disclosure provides a method and an apparatus for concurrent processing of business transaction data. The method and the apparatus use a time slice-centered scheme to cope with the situation where multiple requests demand a same resource at the same time. The system divides the processing time into multiple time slices, allocates each request to a corresponding time slice, and iteratively processes requests according to their corresponding time slices. The system does not require the requests to be processed one by one, and therefore does not cause a situation where other requests have to wait until the current request has been completely processed. Moreover, if a certain time slice has been allocated multiple requests of a same type, the requests are collectively processed as if they were a single request to reduce the frequencies of resource locking and unlocking, as well as the waiting time in a queue for resource access.

In one embodiment, to iteratively process the requests, the system determines whether a present time slice has a request queue containing multiple requests of a same type, and if affirmative, collectively processes the multiple requests of the same type. The system may also determine whether a present request being processed satisfies a concurrency condition, and allocates the present request to the corresponding time slice only if affirmative. If the present request does not satisfy the concurrency condition, the system may process the present request according to a normal handling process. An exemplary concurrency condition is satisfied if the present request is among multiple requests directed towards a same account.

The requests may be allocated to the corresponding time slice according to the receipt time of each request.

In one exemplary embodiment, the processing system is implemented on a third-party payment processing platform. The requests for business data processing may be requests for financial transaction processing including financial account bookkeeping.

An apparatus of business transaction data processing is also provided to implement the disclosed method. According to another aspect of the disclosure, an electronic bookkeeping system implementing the disclosed method is provided. The apparatus or the system may be a part of a third-party payment processing platform.

The present disclosure applies the concept of time slice to network request processing, and allocates special network requests which are highly concurrent to different time periods for processing based on the receipt times of the requests. The method does not require each request be sequentially processed as conventional method does. Rather, the processing is controlled by a reiteration of the allocated time slices. All requests have their share to access the processing resources according to the terms of their corresponding time slices, and are not forced to wait until other requests have been completely processed.

Moreover, if a time slice has multiple requests of a same type, the multiple requests are collectively processed as if they were a single request. This reduces the frequencies of resource locking and unlocking, as well as the waiting time in a queue for resource access.

DETAILED DESCRIPTION

In order to more clearly and easily understand the characteristics and the benefits of the present disclosure, the present disclosure is described below in further detail using accompanying figures and specific exemplary embodiments.

Described are a method and an apparatus of business transaction data processing. Herein, business transaction data processing refers to processing of data in business transactions involving multiple business accounts which require bookkeeping. A typical example of such business transactions is a process of making a payment by a buyer to the seller. In this business transaction, both a buyer's account and a seller's account are involved. The disclosed method and the apparatus are applicable to at least part of this business transaction. For example, the method and the apparatus may be applied in either a buyer's account system or a seller's account system, or both. When the business transaction is conducted from a third-party platform which holds the business accounts of both parties of the transaction, the method and the apparatus may be implemented on such a third-party platform to handle the business transactions involving the business accounts of both parties. As will be described below, the business accounts held on a third-party platform may be virtual accounts, which may be connected with external real bank accounts.

The disclosed method borrows and applies the concept of time slice to network request processing, and allocates special network requests which are highly concurrent to different time periods for processing to solve the problem of a same resource being occupied by a large number of processes at the same time, and improve processing efficiency. Moreover, requests that are combinable within a time slice are processed in combination, reducing frequencies of locking and unlocking of the same resource.

The method can be suitably used in concurrent business processing in various business systems, as explained in details using an example of concurrent account processing in a financial system. The financial system may include a network system of a financial institution and a financial data processing system which is based on a third-party transaction platform.

During the account processing of the financial system, two bookkeeping processes, one for a payment account and another for a recipient account, are involved in one billing request. Therefore, concurrent requests may be multiple payment requests, such as payment requests from multiple transactions submitted to a same recipient account at the same time. Concurrent requests may also be multiple payment collection requests, such as payment collection requests from multiple transactions submitted to a same payment account at the same time. Processing of these high-volume account involving high concurrency transactions (which may include recipient account and a payment account) is described below using the exemplary embodiments. In this description, the order in which a process is described is not intended to be construed as a limitation, and any number of the described process blocks may be combined in any order to implement the method, or an alternate method.

First Exemplary Embodiment

FIG. 1shows a flow chart of a process100of concurrent data processing in accordance with a first exemplary embodiment. Requests directed towards a high-volume account involving high concurrency transaction are processed by a processing system. The process100is described as follows.

At block S101, the processing system divides the processing time into multiple time periods. Each time period is called a time slice. The processing time of the system refers to the time used by the processing system to process transaction requests.

At block S102, the processing system allocates a concurrent request to a corresponding time slice. The allocated concurrent request waits for the assigned corresponding time slice to be processed.

In practice, various allocation strategies, which primarily use division methods based on time periods, may be used for allocation. For example, a minute may be divided into sixty time slices in unit of seconds. Upon receiving a request, the system allocates the request to a time slice corresponding to the time of the request. For instance, if a request is received at the twentieth second, the request is allocated to the twentieth time slice for processing. If concurrent requests are received (i.e., multiple requests directed towards a certain high-volume account involving high concurrency transaction are received at the same time), the multiple concurrent requests are allocated to the same time slice.

At block S103, the system interactively processes the requests in corresponding time slices according to the order of the time slices.

As described below, the present disclosure provides a preferred method for processing requests in each time slice.

At block S104, to process a request queue of a present time slice, the system preferably determines whether there exist requests of a same type. The determination is made based on pre-determined requirements. If search requests exist, the process continues to S105. If such requests to not exist, the process proceeds to S106.

The requests of the same type refer to requests that are combinable for processing, such as payment requests that are directed towards a same account, payment collection requests that are directed towards a same account, and requests of a same type of transactions or requests of the same transaction that are directed towards a same account, etc.

At block S105, the requests of the same type, if determined to exist, are combined to be processed together.

At block S106, where there are no requests of a same type, each request is processed separately.

In general, bookkeeping of two accounts (e.g., a payment account and a recipient account) is involved in account processing. In order to completely process a request, each account needs to perform an account locking operation and unlocking operation. If requests are of a same type, the multiple requests directed towards a same account may be combined so that processing may be completed by performing a single operation of locking and unlocking. If requests are not of a same type, relevant accounts need to be locked and unlocked when each request is processed.

At block S107, the system returns a processing result.

The disclosed processing method uses a time slice-centered approach to solve the problem of concurrent occupation of a same resource and to improve concurrent processing efficiency of a system. A certain request gets its share of being processed when its corresponding time slice's turn arrives, regardless of the processing status of the other requests. In comparison, the existing technologies are request-centered and process requests in turn. When a request is being processed, the system is devoted to the current process to complete it, and other requests have no chance to be processed until the current request has been completely processed.

Moreover, in some preferred embodiments, the disclosed method processes the requests allocated to a same time slice efficiently. Requests of a same type within the same time slice are processed in combination. This reduces the number of separate processes, the frequency of locking and unlocking operations of a resource, as well as the waiting time in a queue for resource access.

Preferably, in a practical application, the process may further include a pre-processing procedure. Prior to allocating a concurrent request to a corresponding time slice, the procedure first identifies a request, and gives consideration to the identified information (e.g., the type of the request) when allocates the request.

In one embodiment, the processing unit may determine whether a present request being processed satisfies a concurrency condition, and allocate the present request to the corresponding time slice for time slice-based processing only if the determination is affirmative. If the present request does not satisfy the concurrency condition, the present request may not be allocated to a time slice but instead be processed according to a normal handling process. An exemplary concurrency condition is satisfied if the present request is among multiple requests directed towards a same account. This is described in further detail with reference toFIG. 2.

FIG. 2shows a schematic diagram illustrating an exemplary processing technique200in accordance with the present disclosure. At a decision block210of processing a bookkeeping request, a system first determines whether a present request is a concurrent request based on pre-determined configuration information. If the present request is a concurrent request, the request is sent to a special bookkeeping process which allocates a corresponding time slice212to the request, which waits the turn of its corresponding time slice to be processed at214. If requests of a same type exist in a same time slice, the requests are combined for processing at216. Bookkeeping220is conducted when the allocated corresponding time slice is processed. The time-sliced process of212,214and216may use any embodiment of the time-slice based processing technique disclosed herein (e.g., the process ofFIG. 1). If the present request is determined at block210to be not a concurrent request, the request is sent to a normal process211for bookkeeping220. Any available processing technique may be used for the normal process211.

The above special bookkeeping refers to processing that is conducted specially for high-volume businesses or accounts. In order to distinguish which request needs to be specially processed, certain configuration information may be determined in advance. The configuration information defines which business is to be considered a high-volume business, and which type of data processing within the business is to be concurrent processing, etc. The configuration information can be defined according to the specific nature of the business, aiming to pick out highly concurrent processing requests send them to a special handling process for time slice-based processing.

The present disclosure further provides an exemplary apparatus of concurrent data processing to implement the method described herein. This is described with reference toFIG. 3below.

FIG. 3shows a structural diagram of an exemplary apparatus300of concurrent data processing. The apparatus300primarily includes a time slicing unit301, a request allocation unit302, and a time slice processing unit304. The time slicing unit301is used for dividing processing time into multiple time slices. The request allocation unit302is used for allocating a concurrent request to a corresponding time slice. The time slice processing unit304is used for iteratively processing requests in corresponding time slices according to an order of the time slices.

Preferably, the time slice processing unit304includes an iterative scheduling unit used for iteratively scheduling the requests in each time slice, and a combined processing unit used for determining whether requests of a same type exist in a request queue of a present time slice based on pre-determined requirements. If such requests exist, the combined processing unit combines the requests of the same type for processing. Otherwise, the processing unit303separately processes each request.

In one embodiment, the apparatus300further includes a normal processing unit303to process a request according to a normal handling process if the present request is not a concurrent request. In order to do this, the request allocation unit302may include a determination unit used for determining whether a present request is a concurrent request based on pre-determined configuration information. The request allocation unit302allocates the present request to a time slice if the present request is determined to be a concurrent request by the determination unit.

The normal processing unit303and the time slice processing unit304are two different processing channels. The normal processing unit303may conduct the processing using a method of existing technologies which is separately locks the accounts that are involved in a request, processes the request and performs bookkeeping, and unlocks the accounts upon completing the processing. The time slice processing unit304, on the other hand, is used for performing special processing of a high-volume business or an account. As illustrated, the efficiency of concurrent processing may be improved using methods of time slicing and combining requests of a same type.

Herein, a “unit” is a device which is a tool or machine designed to perform a particular task or function. A unit or device can be a piece of hardware, software, a plan or scheme, or a combination thereof, for effectuating a purpose associated with the particular task or function. In addition, delineation of separate units does not necessarily suggest that physically separate devices are used. Instead, the delineation may be only functional, and the functions of several units may be performed by a single combined device or component. When used in a computer-based system, regular computer components such as a processor, a storage and memory may be programmed to function as one or more units or devices to perform the various respective functions. In one implementation environment, the apparatus300is implemented with one or more server computer.

Any missing details of the apparatus300shown inFIG. 3can be referenced to the related portions of the processes shown inFIG. 1andFIG. 2, and are not repeated herein.

Second Exemplary Embodiment

One important application of the disclosed method is in electronic commerce. The following uses an example of financial data processing based on a third-party transaction platform to illustrate in further detail how the disclosed method is applied in concurrent billing in electronic transaction processing.

In an electronic transaction between two parties, bill processing is implemented by a third-party payment platform. The third-party payment platform has virtual user accounts, which may include a buyer's virtual account, and a seller's virtual account. The buyer first transfers a transaction fund from a bank account into the buyer's virtual account. The transaction fund is then transferred from the buyer's virtual account into the seller's virtual account during a transaction. The transaction fund is under control of the third-party payment platform at that time, so the seller is unable to withdraw the transaction fund from the seller's virtual account. After the buyer confirms receiving goods, the transaction fund is transferred from the seller's virtual account into the seller's bank account by the third-party payment platform.

In the above transaction, a transfer between the two parties' virtual accounts within the third-party payment platform constitutes a billing request which can be processed using the method of the present disclosure. Such a billing request may be a payment request or a payment collection request, as described in the above transaction. With the third-party payment platform that handles transactions of multiple users, such payment requests tend to be concurrent requests.

The following uses an example of concurrent payment request for illustration. An account mentioned below refers to a virtual account. If multiple accounts send payments at the same time, the processing for each payment request includes three parts: (1) a billing system separates the requests into different processing channels based on configuration information; (2) a request is allocated to a time slice; and (3) the time slice is processed in turn. The process is described in further detail below with reference toFIGS. 4-6.

FIG. 4shows a schematic diagram illustrating a process400of separating processing channels by a billing system401based on configuration information.

InFIG. 4, an external system431refers to a system external to the billing system401. An example of the external system431is an electronic transaction system or other business systems that generate requests through user interaction with user432(which may be a buyer or seller). The billing system401is implemented on a third-party payment platform, and is used for processing transfers between the virtual accounts on the third-party payment platform.

Assume that a transfer is being made from an account A to an account B in the billing system401. Upon receiving a request from the external system431, the billing system401determines whether the request is directed towards a high-volume business or a high-volume account involving high concurrency transaction. If yes, request allocation unit402allocates the request to a time slice processing channel404, which processes requests using a time-slice based method as disclosed herein. Further detail of this time slice-based process is described with reference toFIG. 5bill. If the request is determined to be not directed toward a high-volume business or account, the request is allocated to a normal billing processing channel403to be processed using an existing technological method (i.e., a method which separately locks, conducts bookkeeping, and unlocks the two accounts that are involved in the request). The above process is performed for every request received from the external system431.

FIG. 5shows a schematic diagram of a process500allocating a request to a time slice. If a request received from the external system531(through interaction with user532) is allocated to the time slice processing channel504, the request is placed in a corresponding time slice to wait for processing. The corresponding time slice may be selected according to the time of receiving the request. If multiple requests are placed in the same time slice, a request queue540of this time slice is formed.

A typical request involves a transfer of funds between two accounts. One example is making a payment and another is collecting a payment. As illustrated inFIG. 5, after a request for transferring funds from the account A to the account B is placed in a time slice, the time slice processing channel504separates the account A's payment operation and the account B's payment collection operation into two tasks which are arranged in the time slice's queue540. Task1is account A making payment, while Task2is account B that collects the payment.

FIG. 6shows a process600of processing the time slice assigned to the above described request. InFIG. 6, a request allocation unit602allocates a time slice to each transaction request. A time slice iteration handler606is used for scheduling iterative processing of requests in each time slice's queue640. For a target time slice that is presently scheduled, Task1(account A making payment) in the target time slice's queue640is first obtained for payment making processing. Subsequently, Task2(account B collecting the payment) is obtained for payment collection processing. After the Task1and the Task2are completely processed, processing results of the Task1and the Task2are returned to the external system (531).

Because the illustrated example is concerned with processing of concurrent payment requests (i.e., multiple accounts sending payments to one recipient account), bookkeeping is conducted just once for each account that makes the payment (the account A), while bookkeeping for the recipient account (the account B) needs to be conducted multiple times. Therefore, the account A is not a high-volume account involving high concurrency transactions, and only needs to be processed by the account processing unit603/604under normal account processing. Specifically, the account A is locked, processed for bookkeeping, and unlocked for each payment request. The bookkeeping may include voucher recording and account balance update.

In comparison, the account B is a high-volume account involving high concurrency transactions, and therefore may receive multiple requests that are placed in a same time slice. Preferably, in order to reduce frequencies of locking and unlocking of the account B, requests of a same type can be combined and treated as a single request for processing. The Task2of multiple payments is therefore considered combinable and can be added to a general summary table. The summary table collectively records all requests of same type in a same time slice. Combinable payment requests in the summary table are subsequently processed collectively by the account processing unit603/604as if these requests were a single request. That is, the multiple requests for payment collection can be completed by conducting a single cycle of locking, bookkeeping and unlocking operations.

For example, request of payment A→B and request of payment C→B are placed into a time slice1as shown in a table below. After this time slice has been processed, ten dollars are deducted from the account A, and twenty dollars are deducted from the account C. For the high-volume account involving high concurrency transaction B, a result of combined processing is to add thirty dollars in one time.

Similarly, concurrent payment requests E→D and E→F are placed in a time slice2. When this time slice is processed, the concurrent account E is processed in combination (i.e., twenty dollars are deducted in one time), while five dollars are added to the account D, and fifteen dollars are added to the account F.

After the current time slice is completely processed, the account processing unit603/604generates notification of the process completion of the current time slice in the system.

The present disclosure further provides an electronic bookkeeping system to implement the concurrent processing method described above.

FIG. 7shows a structural diagram of an electronic bookkeeping system700in accordance with the exemplary embodiment. The system700includes a request allocation unit702, account processing unit703/704, a time slice iteration handler706, and a storage unit707.

The account processing unit703/704is used for processing transaction requests including conducting bookkeeping such as recording a voucher and updating an account balance. The storage unit707is used for storing transaction requests assigned to corresponding time slices, and can be implemented by a computer-readable memory or storage device. The request allocation unit702is used for allocating a concurrent transaction request to a corresponding time slice according to the time of the request. The time slice iteration handler706is used for iteratively processing the transaction requests in each time slice according to an order of the time slices. In one embodiment, the time slice iteration handler706determines whether requests of a same type exist in a request queue of a present time slice based on pre-determined requirements. If such requests exist, the time slice iteration handler706combines them to be collectively processed by the account processing unit703/704. If such requests do not exist, a time slice iteration handler706lets the account processing unit703/704process the requests separately.

Preferably, the request allocation unit702may be further configured to determine whether a present request is a concurrent request based on pre-determined configuration information, and to allocate the present request to a time slice for time slice-based processing if the present request is a concurrent request, or send the present request to the account processing unit703/704for normal bookkeeping if the present request is not a concurrent request.

When used in a computer-based system, regular computer components such as a processor, a storage and memory may be programmed to function as one or more units or devices to perform the various respective functions. In one implementation environment, the electronic bookkeeping system700is implemented with one or more server computer.

The above-described techniques may be implemented with the help of one or more computer-readable media containing computer-executable instructions. The computer computer-executable instructions enable a computer processor to perform a competitive resource allocation in accordance with the techniques described herein. It is appreciated that the computer readable media may be any of the suitable memory devices for storing computer data. Such memory devices include, but not limited to, hard disks, flash memory devices, optical data storages, and floppy disks. Furthermore, the computer readable media containing the computer-executable instructions may consist of component(s) in a local system or components distributed over a network of multiple remote systems. The data of the computer-executable instructions may either be delivered in a tangible physical memory device or transmitted electronically.

The electronic bookkeeping system700differs from the conventional request-centered processing in its using time slice-centered processing. In some embodiments, the system700collectively processes requests of a same type within a same time slice. The method may improve the efficiency of accessing a same resource involving high-volume business, reduce frequencies of resource locking and unlocking, and decreasing the pressure on the system700.

It is appreciated that the potential benefits and advantages discussed herein are not to be construed as a limitation or restriction to the scope of the appended claims.