IE84158B1 - Real time transaction processing - Google Patents

Real time transaction processing Download PDF

Info

Publication number
IE84158B1
IE84158B1 IE2002/0051A IE20020051A IE84158B1 IE 84158 B1 IE84158 B1 IE 84158B1 IE 2002/0051 A IE2002/0051 A IE 2002/0051A IE 20020051 A IE20020051 A IE 20020051A IE 84158 B1 IE84158 B1 IE 84158B1
Authority
IE
Ireland
Prior art keywords
database
record
call
functions
category
Prior art date
Application number
IE2002/0051A
Other versions
IE20020051A1 (en
Inventor
Campbell Michael
O Hara David
Corbin Jon
Crowe Gary
Original Assignee
Kbs Solutions Limited
Filing date
Publication date
Application filed by Kbs Solutions Limited filed Critical Kbs Solutions Limited
Priority to IE2002/0051A priority Critical patent/IE84158B1/en
Publication of IE20020051A1 publication Critical patent/IE20020051A1/en
Publication of IE84158B1 publication Critical patent/IE84158B1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23Updating
    • G06F16/2308Concurrency control
    • G06F16/2336Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
    • G06F16/2343Locking methods, e.g. distributed locking or locking implementation details
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2355Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving reformatting operations of additional data, e.g. HTML pages
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26283Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for associating distribution time parameters to content, e.g. to generate electronic program guide data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/435Processing of additional data, e.g. decrypting of additional data, reconstructing software from modules extracted from the transport stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/436Interfacing a local distribution network, e.g. communicating with another STB or one or more peripheral devices inside the home
    • H04N21/43615Interfacing a Home Network, e.g. for connecting the client to a plurality of peripherals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47End-user applications
    • H04N21/482End-user interface for program selection
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/654Transmission by server directed to the client
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65Transmission of management data between client and server
    • H04N21/658Transmission by the client directed to the server
    • H04N21/6582Data stored in the client, e.g. viewing habits, hardware capabilities, credit card number

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.
IE2002/0051A 2002-01-30 Real time transaction processing IE84158B1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
IE2002/0051A IE84158B1 (en) 2002-01-30 Real time transaction processing

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
IEIRELAND31/01/20012001/0074
IE20010074 2001-01-31
IE2002/0051A IE84158B1 (en) 2002-01-30 Real time transaction processing

Publications (2)

Publication Number Publication Date
IE20020051A1 IE20020051A1 (en) 2002-08-07
IE84158B1 true IE84158B1 (en) 2006-02-22

Family

ID=

Similar Documents

Publication Publication Date Title
US8271477B2 (en) Methods and systems for accessing data
US5956728A (en) Object graph editing context and methods of use
EP1121639B1 (en) Impact analysis of a model
US5751958A (en) Allowing inconsistency in a distributed client-server application
EP1049994B1 (en) A method for synchronizing the schema of a database with its representation in an object-oriented repository
US6353828B1 (en) Concurrency control for transactions that update base tables of a materialized view using different types of locks
US6859919B1 (en) Object modeling tool with meta model semantic registry (rules) a meta data manager for object(s) properties an object/property interface for instance(s) of objects/properties received via object/property interface of the object factory registry
US9053143B2 (en) Allowing updates to database objects
US7571197B2 (en) Method and apparatus for synchronizing dataset object properties with underlying database structures
US20050262124A1 (en) Method and apparatus for aggregated update of dataset records in a JavaScript environment
US20060161589A1 (en) Simplifying Movement of Data to Different Desired Storage Portions Depending on the State of the Corresponding Transaction
EP1231550B1 (en) Real time transaction processing
IE84158B1 (en) Real time transaction processing
US20050262070A1 (en) Method and apparatus for combining of information across multiple datasets in a JavaScript environment
US20050262037A1 (en) Method and apparatus for controlling result dataset generation in a javascript environment
US20050262156A1 (en) Method and apparatus for informational comparison of multiple datasets in a javascript environment
US7206786B2 (en) Method and system for adapting memory-resident database in flexible service logic execution environment
CN116802624A (en) Techniques for managing data using data entities and inheritance in a data processing system
US20050262140A1 (en) Method and apparatus for argument parameterization of complex dataset operations
Frank Overview of the Benefits and Costs of Integrating Heterogeneous Applications by Using Relaxed ACID Properties