AU2010202059B2

AU2010202059B2 - Transaction processing system and method

Info

Publication number: AU2010202059B2
Application number: AU2010202059A
Authority: AU
Inventors: Ulf Abrink; Sven Hakan Andersson
Original assignee: Videobet Interactive Sweden AB
Current assignee: Videobet Interactive Sweden AB
Priority date: 2007-02-01
Filing date: 2010-05-20
Publication date: 2013-10-03
Anticipated expiration: 2028-01-23
Also published as: AU2008200338B2; AU2010202059A1; AU2008200338A1

Abstract

Abstract A transaction processing system (100) comprising a back 5 end database server (110) storing a client data record of a client; and a front end database server (120) in data communication with the back end database server, the front end database server (120) arranged to retrieve data from the client data record when the client (130) connects to 10 the front end database server (120) and to thereafter process transactions related to the retrieved data, the front end database server (120) further arranged to communicate data to the back end database server (110) to update the client data record based on the processed is transactions. 2281606 I (GHMaters) P71099AU 2 20/05/10 Z c) Z U) U LLIL < ~zC LuL 0 0 () 0O uJ <- F- 0dL uj (0 cooc co 00L z w Z U) z 0u <C?) Z U)

Description

AUSTRALIA Patents Act 1990 COMPLETE SPECIFICATION Divisional Patent Applicantss: ACEI AB Invention Title: TRANSACTION PROCESSING SYSTEM AND METHOD The following statement is a full description of this invention, including the best method for performing it known to me/us: -2 Title TRANSACTION PROCESSING SYSTEM AND METHOD 5 Related Application This application is a divisional application of Australian application 2008200338 the disclosure of which is incorporated herein by reference. Most of the disclosure io of that application is included herein by reference, however, reference may be made to the specification of application 2008200338 as filed or accepted to gain further understanding of the invention claimed herein. 15 Field The present invention relates to a transaction processing system and a transaction processing method. 20 Background to the Invention In the gaming industry, there is a move towards server based gaming systems where the majority of the gaming functions are implemented on a server and the gaming 25 machines played by players are clients of the server. For such implementations to be effective, transactions between the gaming machines (also known as gaming terminals) and the server need to be carried out in real 30 time. That is, without any delay that is apparent to the player. Where there are a larger number of gaming machines connecting to a server, the server can be exposed to high 35 loads and hence in a gaming system with a large number of gaming machines, the server may require significant CPU processing power, particularly in light of the fact that 2281606_1 (GHMaters) P71099.AU.2 20/05/10 - 3 the relationship between increased load and CPU power is not linear. This can result in a high investment cost for hardware. 5 Accordingly, there is a need for an architecture suitable for a gaming system that is capable of handling high transaction loads. Summary of the Invention 10 In a first aspect, there is disclosed a transaction processing system comprising: a client arranged to send a connection request including a transaction to be processed; is a backend database server maintaining a database, said database storing a client data record of the client; and a front end database server in data communication with the backend database server, the front end database server being arranged to selectively accept or refuse the 20 connection request from the client, wherein upon refusing the connection request, the front end database server provides the client with an identity of another front end database server, and wherein upon accepting the connection request, the front end database server retrieves data from 25 the client data record and thereafter processes the transaction received from the client related to the retrieved data including, 1) updating the retrieved data based on the transaction, 2) storing the updated data in the frontend database server, and 3) communicating the 30 stored updated data to the back end database server; and wherein the back end database server stores the communicated updated data in the client data record in the database. 35 In an embodiment, the back end database server stores client data records for each of a plurality of clients. 2281606_2 (GHMatters) P71099.AU.2 P71099. AU.2 6/09/13 - 4 In an embodiment, the transaction system comprises a plurality of front end database servers, each in data communication with the back end database server, the front end database servers arranged to share connection requests 5 from clients amongst one another. In an embodiment, the transaction system comprises at least one an application server arranged such that each client connects to a front end database server via the io application server. In an embodiment, the transaction system comprises a plurality of clients in data communication with the front end database server. 15 In an embodiment, each client is a gaming terminal. In an embodiment, the front end database server processes transactions based on data communicated from the client. 20 In an embodiment, the transaction system is further arranged to transfer responsibility for processing transactions of a client from a failed front end database to another front end database server. 25 In a second aspect there is disclosed a transaction processing method for use with a system having a client, a plurality of frontend database servers, and a backend database server, wherein the backend database server 30 maintains a database, the method comprising: storing a data record for the client in the database; sending from the client a connection request including a transaction to be processed; retrieving data at the frontend database server from 35 the backend database server, selectively accepting or refusing a connection request from the client to one of the frontend database servers, 2281606_2 (GHMatters) P71099.AU.2 P71099.AU.2 6/09/13 - 4a wherein upon refusing the connection request, the one frontend database server providing the client with an identity of another frontend database server, and wherein upon accepting the connection request, the one frontend 5 database server retrieving data from the data record of the client; and when the client connects to the frontend database server: processing the transaction related to the 10 retrieved data at the frontend database server including: 1) updating the retrieved data based on the transaction; 2) storing the updated data in the frontend database server; and is 3) communicating the stored updated data from the frontend database server to the backend database server; and storing the communicated updated data in the client data record in the database via the backend 20 database server. In an embodiment, the transaction processing comprises processing transaction related to the retrieved data based on data communicated from the client. 25 Brief Description of the Drawings An embodiment of the invention will now be described in relation to the accompanying drawings in which: 30 Figure 1 is a block diagram of a transaction 2281606_2 (GHMatters) P71099.AU.2 P71099.AU.2 6/09/13 -5 processing system; and Figure 2 is a flow chart of a transaction processing method. 5 Detailed Description Referring to the drawings there is shown a transaction processing system 100 and method for a database based gaming system that is designed to handle high loads in a 1o real-time environment. The transaction processing system 100 has a back end database server (BEDS) 110 that is the focal point of the system where all data needed by different nodes is shared. is The back end database server 110 is also where all client data is stored. The gaming system 100 has a plurality (N) of front end database servers (FEDS) 120A-120E adapted to receive connection requests from a plurality (M) of clients 130A-130G. Clients 130E and 130F are shown as 20 connecting to front end database server 120D via an application server 125 to illustrate that depending on the embodiment, none, some or all of the clients 130A-130G may connect to a front end database server 120 via an application server 125. 25 When a front end database server 120 is started, it connects 210 to the back end database server 110. When a front end database server 120 receives a connection request from a client, it either accepts the request or 30 passes the client the identity of another front end database server 130 if this will achieve load balancing between the plurality of front end database servers 120. Load balancing data is communicated between the front end database servers 120. 35 If the front end database server 120 accepts the request, it requests client data 220 from the back end database 2281606_ 1 (GHMattes)P71099 AU 2 20/05/10 -6 server 110. The back end database server 110 retrieves either the entire data record for the client from database 115 or a subset of data that is expected to be accessed frequently. The back end database server 110 then 5 communicates the relevant data to the front end database server 120. Examples of data that may be transferred to the front end database server include status, number of notes, number of coins in the coin acceptor, etc. 10 Once the front end database server 120 accepts the request it will accept transaction requests from the client 130, for example, to update a current record of the credit meter in the database. The front end database server 120 processes the request 230, updates the local version of is the client data and waits 240 for further transactions. The front end database server 120 also starts a parallel process 260-275 to update the client data stored in database 115 of back end server database. That is the 20 front end data base server 120 sends update data to the back end database server 110 which updates 265 the database 115. In this manner, the front end database server 120 is able 25 to process the transaction requests in real-time while the back end server 110 is updated in near real-time. When there are no more transactions, the front end database server 120 returns control of the data to the 30 back end database server 120. This process involves determining that all data has been updated 270 so that the database 115 is synchronised to the data that has been updated locally by the front end database server 120. 35 A number of additional features provide additional robustness to the handling of transactions. Specifically, the system is designed such that when application servers 2281606_1 (GHMatters) P71099.AU-2 20/05/10 -7 125 are employed, a client can fail over from one application server to another and hence that ownership of a client can be moved from one application server or front end database server 120 to another. If application servers 5 are not employed the system is designed so that a client can fail over from one front end database server 120 to another so that ownership of a client can be moved from one front end database server 120 to another. In addition, an application server can be reconfigured to connect to a io different front end database server 120. The system can employ "hot" or "cold" standby servers and the front end database servers 120 can fail over to their standby configuration. The back end database server 110 can also fail over to its standby configuration. 15 Alternatively, or in addition to employing standby services, the system can employ Real Application Clusters which allow multiple instances on different nodes to access a shared database on a cluster system for load 20 balancing. These and other modifications will be apparent to persons skilled in the art and should be considered as falling within the scope of the invention described herein. 25 In the claims which follow and in the preceding description of the invention, except where the context requires otherwise due to express language or necessary implication, the word "comprise" or variations such as 30 "comprises" or "comprising" is used in an inclusive sense, i.e. to specify the presence of the stated features but not to preclude the presence or addition of further features in various embodiments of the invention. 35 It is to be understood that, if any prior art publication is referred to herein, such reference does not constitute an admission that the publication forms a part of the 2281606_ I (GHIMatters) P71099 AU 2 20/05/10 -8 common general knowledge in the art, in Australia or any other country. 2281606_1 (GHMatters) P71099 AU2 20/05/10

Claims

1. A transaction processing system comprising: a client arranged to send a connection request 5 including a transaction to be processed; a back end database server maintaining a database, said database storing a client data record of the client; and a front end database server in data communication with 10 the back end database server, the front end database server being arranged to selectively accept or refuse the connection request from the client, wherein upon refusing the connection request, the front end database server provides the client with an identity of another front end is database server, and wherein upon accepting the connection request, the front end database server retrieves data from the client data record and thereafter processes the transaction received from the client related to the retrieved data including, 1) updating the retrieved data 20 based on the transaction, 2) storing the updated data in the front end database server, and 3) communicating the stored updated data to the back end database server; and wherein the back end database server stores the communicated updated data in the client data record in the 25 database.

2. A transaction system as claimed in claim 1, wherein the back end database server stores client data records for each of a plurality of clients. 30

3. A transaction system as claimed in claim 2, and further comprising a plurality of front end database servers, each in data communication with the back end database server, the front end database servers arranged 35 to share connection requests from clients amongst one another. 2281606_2 (GHMatters) P71099.AU.2 P71099.AU.2 6/09/13 - 10

4. A transaction system as claimed in any one of claims 1 to 3, and further comprising at least one an application server arranged such that each client connects to a front end database server via the application server. 5

5. A transaction system as claimed in any one of claims 1 to 4, and further comprising a plurality of clients in data communication with the front end database server. 10

6. A transaction system as claimed in claim 5, wherein each client is a gaming terminal.

7. A transaction system as claimed in claim 5, wherein the front end database server processes transactions based 15 on data communicated from the client.

8. A transaction system as claimed in claim 3, further arranged to transfer responsibility for processing transactions of a client from a failed front end database 20 server to another front end database server.

9. A transaction processing method for use with a system having a client, a plurality of front end database servers, and a back end database server, wherein the back 25 end database server maintains a database, the method comprising: storing a data record for the client in the database; sending from the client a connection request including a transaction to be processed; 30 retrieving data at the front end database server from the back end database server, selectively accepting or refusing a connection request from the client to one of the front end database servers, wherein upon refusing the connection request, the one 35 front end database server providing the client with an identity of another front end database server, and wherein upon accepting the connection request, the one front end 2281606_2 (GHMatters) P71099. AU.2 P71099.AU.2 6/09/13 - 11 database server retrieving data from the data record of the client; and when the client connects to the front end database server: 5 processing the transaction related to the retrieved data at the front end database server including: 4) updating the retrieved data based on the transaction; 5) storing the updated data in the front end 10 database server; and 6) communicating the stored updated data from the fron tend database server to the back end database server; and storing the communicated updated data in the 15 client data record in the database via the back end database server.

10. A transaction processing method as claimed in claim 9, and further comprising processing the transaction related 20 to the retrieved data based on data communicated from the client 2281606_2 (GHMatters) P71099.AU.2 P71099.AU.2 6/09/13