IE84158B1 - Real time transaction processing - Google Patents

Description

Real time transaction processing" INTRODUCTION Field of the Invention The invention relates to a real time transaction processing system of the type comprising:- a client layer comprising a plurality of client computers programmed with a graphical user interface, with applications to execute data processing operations locally, and with functions to perform data manipulation operations in communication with a server; a communications layer; and a database server comprising stored database tables and database functions comprising means for communicating with the client computers.

Prior Art Discussion Heretofore, in such systems the client data manipulation functions include data aware controls for manipulation of data in a manner which is directly controlled by them.

Also, the database functions of the server are low-level functions such as SQL statements, which perform low-level data access operations under direct control of the client computer data aware controls. An example of such a system is disclosed in British Patent Specification No. GB2201270B (and corresponding US515l988). In this document, a journal merge key table stores transaction sequence information, and a lock manager communicates with other processors each time there is access to modify a selected record.

This approach simplifies the programming effort and allows the client computers to be quite powerful and effective at meeting the user requirements for a range of data processing activities and real time transaction processing. It also provides comprehensive and versatile user interfacing in a window environment.

However, concurrency problems for real time transaction processing arise where there are multiple client computers. These concurrency problems arise from uncoordinated many-to-one database access and record locking operations. This gives rise to frequent record locking conflicts in an environment with typically, over client computers.

The invention is therefore directed towards providing a real time transaction processing system having the above—described benefits of powerful client computes without these concurrency problems.

SUMMARY OF THE INVENTION According to the invention, there is provided a real time transaction processing system as set out in claim 1.

In one embodiment, each maintenance function comprises means for incrementing a counter in a stored database record tag upon performance of a write operation to the record.

In another embodiment, the call interface comprises means for inserting a tag value identifying the requesting client computer in a call to the maintenance function.

In a further embodiment, each maintenance function comprises means for writing the calling client computer identifier tag value to the record when updating a record.

In one embodiment, each maintenance function comprises means for writing a tag value indicating current date and time to a record during an update.

In another embodiment, each read fiinction and each browse function comprises means for reading record tag values together with record data, and for transmitting the tag values to a requesting client computer.

In a further embodiment, each client computer comprises means for associating a unique primary key identifying a record to be updated, and for including said key in a call to a maintenance function for an update.

In one embodiment, each maintenance function comprises means for performing a record update in a single operation having an instruction specifying the update to be performed and an instruction setting a condition of ensuring tag values in the record match those received in the call from the call interface.

DETAILED DESCRIPTION OF THE INVENTION Brief Description of the Drawings The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which:- Fig. 1 is a diagram illustrating architecture of a rea1—time transaction processing system of the invention; and Fig. 2 is a flow diagram showing operation of the system in more detail.

Description of the Embodiments Referring to Fig. l a real time transaction processing system comprises a client layer 1, a communications layer 2, and a database server 3. The client layer 1 comprises in the range of 50 to 100 PC client computers 10 connected to the communication layer The communication layer 2 comprises an ODBC connection from the client computers 10 to the database server 3.

The database server 3 comprises database functions 15 grouped into read, browse, maintenance, and process categories. The functions 15 access relational transaction data tables 16 ofl MB to 10 GB size.

Referring to Fig. 2 each client computer 10 is programmed at the software level with a graphical user interface (GUI) 20, applications 21, and a call interface 22. Within the database functions 15 one function from each of the four categories is illustrated, namely:- a read function 30; a browse function 31; a maintenance function 32; and a process function 33.

The various functions are best described by way of their operations, as follows. A user may, for example, be a bank official dealing with customers either directly or via telephone at a call centre. The user activates the local applications 21 using the GUI in a typical manner for operations such as spreadsheet or word processing. Thus, for example, he or she may generate reports or documentation with the benefit of powerful state-of-the-art applications. However data manipulation functions of standard PC operating systems and applications are redundant in the client computers 10. Instead, each client computer 10 comprises high-level functions in a call interface 22 which generate calls for the database functions 15. These calls identify the required database function category and include at least one argument specifying a parameter value. Also, the database functions 15 are more powerful than heretofore as they not only perform the low—leve1 database interaction operations of conventional database functions, but they also perform higher-level operations.

These higher—level operations include interpreting the call interface calls, performing both complex and simple operations, and communicating replies back to the call interfaces 22.

The call interfaces 22 comprise a number of common procedures which are defined without a database interface, but which provide access to the database server 3 from within these common procedures. The client software is segmented so that any database interaction has been removed from the GUI and is contained strictly within the call interface. The local applications 21 provide common functionality to the GUI 20, but are independent of database considerations.

In addition, another aspect is that the database functions 15 are grouped into categories as described above. The allowed operations of the database functions of each category are well-defined and consistent within the system 1.

All read functions 30 are confined to reading only one database record, and they can not lock the record. All browse functions 31 are confined to reading multiple records and also can not lock the records. All maintenance functions 32 can only perform writes to a single record, and they can perform a record lock only on that single record. Finally, all process functions 33 are confined to:- activating only upon a call from a client call interface 22; operate in batch mode on a full dataset, in which all data of the dataset is retrieved, processed, and the processed data written back; and lock all records of the dataset only during the processing.

Referring again to Fig. 2, the call interface 22 transmits a read call with an argument to a read function 30. An example would be gathering information for a user to decide to cancel a cheque. The current cheque information would be read in a read only fashion to allow the user to decide whether the cheque should be cancelled.

The read function 30 does not lock the relevant record, it only reads data and an update tag from the record and transmits them back to the call interface 22. The tag may, for example, be SYS, Dec. 30 2001, 3.37PM,l. In this tag "SYS" is the identifier of the last user to update the record, in this example an automatic system update. The date and time are of the last update, and the "l" value is a value of a serial number which is incremented with every update to the record. The date and time stamp fields are only ever updated / added by the maintenance functions 32.

The call interface 22 directly passes the data and tag values to the relevant GUI 20 or local application 21. These values are stored by the GUI 20 or local application 21 and are required to be subsequently passed back to the call interface 22 whenever any database action is requested.

A call to a browse function 30 includes an argument specifying multiple data records.

As for the read function 30, the data and tags are read and passed back without any record locking. Of course, in this case a full dataset is passed back, including data and appended tags.

A call to a maintenance function 32 has an argument specifying a data record to be updated with a write operation and the value to be written. An example of such a call is updating fields on a customer record to reflect changes in address information. The maintenance function 32 may insert new data, in which case the call interface 22 provides default tags, or updating data using tag values and a unique primary key. In the latter case, if the data is the same as was read from the database, then the function 32 will lock the record and the update will be successful. If the data has been changed then the function 32 will not perform the requested update and a fail notification is returned to the call interface 22. This is detected by the maintenance function 32 because the tags are different. The tags being different indicates that another client computer 10 has updated the record in the intervening period. Thus, the basis on which a requesting client computer (10) requested the update has changed since it received the data from the read function 30, and a "write fail" helps to preserve data integrity.

In more detail, the following is an example of a call for a maintenance function 32.

"CoExecute (DmBranchesMaint l, 1, 'KBS BankName', 'SYS', ‘Dec 30 2001 3:37PM‘, 1, 'JC')" in which:- "CoExecute" activates the communications layer 2 to perform a transfer to the database server 3, "DmBranchesMaint" is the name of the maintenance function 32, "l " is the primary key identifying uniquely the record, " 1" is the branch number (data), "KBS BankName" is the new value of the description (data), "SYS" is the last client to update, as read previously by the read function 30, "Dec 30 2001 3:37PM" is the last updated date, as read previously by the read function 30, " l " is the serial as read previously by the read function 30, and "J C" identifies the new (current) 10 client generating the call.

The maintenance function DMBranchesMaint then performs: UPDATE Table SET Branch: 1 BranchName = 'KBS BankName' AudUser = 'JC' AudDate = GetDate() AudSerial = AudSerial + 1 WHERE PriimaryKey = 1 AND AudUser = 'SYS' AND AudDate = ‘Dec 30 2001 3:37PM’ AND AudSerial = 1 In this example the "SET" parameters are used to perform a write, only if the tag values in the record exactly match those of the "WHERE" statement, i.e. SYS, Dec. 2001, and 3:37 PM. It will be noted from the "SET" statement that the new tag values in the record following the update will indicate that the last update user was "JC", the date and time are those of the current system, and the serial number is incremented by 1.

Because the "SET" and "WHERE" statements are included in the one operation the update is atomic, it only occurs if the "WHERE" values match those of the record.

Calls to the process fiinctions 33 are much less frequent than those to the other database functions 30, 31, and 32. This is because they arise only when a client Computer 10 requires batch processing for a dataset of multiple records. An example would be activation of a new car loan, where the process of activation could spawn up to 50 financial transactions. All of the records in the dataset are locked during the processing. However, this has little impact on the system 1 as a whole because such processing is relatively infrequent (much of the financial data associated with the application results from end-of-day functions, which are run in single user mode).

Atomicity of the process functions 33 is achieved using begin transaction / commit transaction functions on the database.

It will be appreciated that the client computers 10 provide a wide range of data/ document processing operations as requested via the GUI 20. In addition they achieve the real time database access required for the transaction processing environment without actually performing the operations themselves. They only need to generate calls to database functions in selected categories for database access.

Because the full range of database interaction operations are performed locally at the database server 3 in the manner described, these operations are much more co- ordinated and involve considerably less record locking than heretofore. For example, the prior approach involved locking during a user dialogue, thus leading to concurrency problems and potential deadlock scenarios. The invention also provides a clearly defined architecture that allows for a consistent approach to the maintenance of data and transaction processing. This allows new functionality to be produced without compromising the structure already defined within the application.

As new applications or GUI functionality are added, it is only required that they use the call interface 22.

The invention is not limited to the embodiments described but may be varied in construction and detail.

Claims (1)

1.Claims A real time transaction processing system comprising: a client layer (1) comprising a plurality of client computers (10) programmed with a graphical user interface (20), local applications (21) to execute data processing operations and with functions locally, to perform data manipulation operations in communication with a server (3); a communications layer (2), and a database server (3) comprising stored database tables (16) and database functions (15) comprising means for communicating with the client computers (10); characterised in that, each client computer (10) comprises, at the software level, a call interface (22) comprising means for receiving data manipulation requests from the graphical user interface (20) and from the local applications (21), for generating database function call signals each identifying a database function category and at least one database record, and for transmitting said calls via the communications layer (2) to the database server (3); wherein, within the client computers (10), all database interactions are performed by the call interface (22) and not by the graphical user interface (20) or the local applications (21); the call interfaces (22) comprise a plurality of common procedures which are defined without a database interface; the database functions (15) are grouped according to the following categories:— a read category, a browse category, a maintenance category, and a process category; database functions (30) of the read category are confined to performing on1y:— read database access, access to only a single database record, and leaving an unlocked record unlocked; database functions (31) of the browse category are confined to performing only:— read database access, and leaving accessed unlocked database records unlocked; database functions (32) of the maintenance category are confined to performing only:— access to only a single database record, locking an unlocked database record only when performing a write, and immediately unlocking the record when the write is complete, and confirming a write operation only if all steps for atomicity of the write operation have been completed; and database functions (33) of the process category are confined to performing only:— accessing a plurality of unlocked database records and locking all of the records, and immediately processing the records after retrieval, and immediately unlocking the records after writing processed data to the records; and wherein each maintenance function comprises means for:- receiving record tag values in a client call interface (22) call signal, said values being for the last update known to the calling client computer (10), performing a write operation to the record only if the record tag values are the same as those received in the call, and transmitting a write fail signal to the client call interface (22) if the tags are different. A system as claimed in claim 1, wherein each maintenance function comprises means for incrementing a counter in a stored database record tag upon performance of a write operation to the record. A system as claimed in claims 1 or 2, wherein the call interface comprises means for inserting a tag value identifying the requesting client computer (10) in a caH to the maintenance function. A system as claimed in claim 3, wherein each maintenance function comprises means for writing the calling client computer identifier tag value to the record when updating a record. A system as claimed in any of claims 1 to 4, wherein each maintenance function comprises means for writing a tag value indicating current date and time to a record during an update. A system as claimed in any preceding claim, wherein the read functions (30) and the browse functions (31) each comprise means for reading record tag Values together with record data, and for transmitting the tag values to a requesting client computer (10). A system as claimed in any preceding claim, wherein each client computer (10) comprises means for associating a unique primary key identifying a record to be updated, and for including said key in a call to a maintenance function for an update. A system as claimed in any preceding claim, wherein each maintenance function comprises means for performing a record update in a single operation having an instruction specifying the update to be performed and an instruction setting a condition of ensuring tag values in the record match those received in the call from the call interface. A computer program product comprising software code for performing operations of a real time transaction processing system as claimed in any preceding claim when executing on a digital computer.