System and method for failover

• US 7,188,273 B2
• Filed: 11/24/2003
• Issued: 03/06/2007
• Est. Priority Date: 11/24/2003
• Status: Active Grant

• Current Assignee: TSX Inc. (TMX Group Limited)
• Original Assignee: TSX Inc. (TMX Group Limited)
• Inventors: Morosan, Tudor, Allen, Gregory Arthur
• Primary Examiner(s): Bonzo; Bryce P.
• Application Number:
  US10/718,616
• Publication Number:
  US 20050138461A1
• Time in Patent Office: 1,198 Days
• Field of Search: 714/6
• US Class Current: 714/6.3
• CPC Class Codes: G06F 11/1482 by means of middleware or OS functionality
• CPC Class Codes: G06F 11/1687 at event level, e.g. by interrupt or result of polling
• CPC Class Codes: G06F 11/2007 using redundant communication media
• CPC Class Codes: G06F 11/2028 eliminating a faulty processor or activating a spare
• CPC Class Codes: G06F 11/2041 with more than one idle spare processing component
• CPC Class Codes: G06F 11/2046 where the redundant components share persistent storage G06F11/2043 takes precedence
• CPC Class Codes: G06F 11/2071 using a plurality of controllers
• CPC Class Codes: G06F 11/2097 maintaining the standby controller/processing unit updated initialisation or re-synchronisation thereof G06F11/1658 and subgroups

Abstract

The present invention provides a novel system and method for failover. In an embodiment, a primary server and a backup server are available to a plurality of clients. Messages containing requests are processed by the primary server, while a mirror image of transaction records generated by the processing of those requests is maintained in volatile memory of both the primary server and the backup server. In this mode of operation, the volatile memory is periodically flushed to non-volatile memory.

Claims

1. A system for failover comprising at least one client connectable to a plurality of interconnectable servers, each of said servers operable to process messages from said client and maintain at least transaction record respective to each said message in a transaction log stored in volatile storage, and further operable to flush said transaction log to a non-volatile storage device respective to said server after each said message is processed, wherein when more than one server is available then only one of said servers processes said messages and a remainder of said servers maintain a mirror image of said transaction log, said transaction logs being flushed on a periodic basis, and wherein when only one of said servers is available then said transaction log is flushed more frequently than said periodic basis.

2. The system according to claim 1 wherein said periodic basis is an interval based on one of the criteria selected from the group consisting of a fixed time interval;

a predetermined number of said transaction records having been stored in said volatile storage; and

a time when said volatile storage of a respective one of said servers needs to be freed for other purposes.

3. The system according to claim 1 wherein said servers are connectable to said clients via first network and wherein said servers are interconnect able with each other via a second network.

4. The system according to claim 3 wherein said second network comprises a main link and a failsafe link.

5. The system according to claim 3 wherein said first network is selected from the group consisting of the Internet, a local area network and a wide area network.

6. The system according to claim 1 wherein said client is selected from the group consisting of a personal digital assistant, a cellular telephone, a laptop computer and an email paging device.

7. The system according to claim 1 wherein said servers include a primary server and a backup server.

8. The system according to claim 7 wherein when said backup server is processing requests, said backup sewer is operable to assume the role of said primary sewer when said primary sewer becomes available and at which point said primary server assumes the role of said backup server.

9. The system according to claim 7 wherein said primary server and said backup server are implemented on a single computing environment that is logically partitioned into said primary server and said backup server.

10. The system according to claim 7 wherein said servers include a plurality of software components comprising at least one application process that operates in a hot state to process said messages and otherwise operates in a warm state.

11. The system according to claim 10 wherein when said primary server is available then said primary server application process operates in said hot state, and when said primary server is unavailable then said backup servers bring its application process from said warm state to said hot state and is thereafter operable to process said messages from said clients.

12. The system according to claim 10 wherein said software components include a failover agent executing on each of said servers and communicating with each to verify whether each other said server is available.

13. The system according to claim 12 wherein when said primary server failover agent fails to communicate with said backup server failover agent then said primary server begins operating in a primary-only mode during which said primary server transaction log is flushed after each message.

14. The system according to claim 12 wherein when said backup server failover agent fails to communicate with said primary sewer failover agent then said backup server begins operating in a backup-only mode during which said backup server transaction log is flushed after each message.

15. The system according to claim 10 wherein said software components include a replication agent executing on each of said servers and communicating with each other to maintain said mirror image when both of said servers are available.

16. The system according to claim 10 wherein said software components include a checkpoint agent executing on each of said sewers and communicating with its respective transaction log, said checkpoint agent for flushing its respective transaction log to non-volatile storage.

17. The system according to claim 1 wherein said servers are operable to determine whether a received one of said messages is a duplicate and to return a result of a stored record representing a previous processing of said message in lieu of processing said message.

18. The system according to claim 1 wherein said message includes an Identifier of said client, a message identifier, and a message body.

19. The system according to claim 18 wherein said message body includes a request to purchase or sell a financial instrument.

20. The system according to claim 1 wherein said message includes a request that is processed as at least one discrete transaction, each of said transactions generating at least one transaction log record.

21. A method for operating a system for failover comprising the steps of:

receiving, at a primary server, a request from a client;

processing, at said primary server, said request as at least one transaction;

saving, in volatile memory of said primary server, a transaction record respective to said at least one transaction;

generating, at said primary server, a request to commit said transaction;

mirroring said transaction record in volatile memory of said backup sewer; and

, acknowledging, in said primary server, said commit request if said mirroring is successfully confirmed;

repeating the foregoing steps for additional received messages; and

immediately flushing said primary sewer volatile memory to non-volatile memory if said mirroring is unsuccessfully confirmed; and

, thereafter ceasing further performance of said mirroring step; and

, thereafter flushing each said transaction record to non-volatile memory after said saving step.

22. A method for operating a system for failover comprising the steps of:

receiving, at a primary server, a request from a client;

determining whether said request is a duplicate request, and if said request is a duplicate request, then returning, to said client, a previously stored result of processing said request and if said request is not a duplicate request, then

processing, at said primary server, said request as at least one transaction;

saving, in volatile memory of said primary server, a transaction record respective to said at least one transaction;

generating, at said primary server, a request to commit said transaction;

mirroring said transaction record in volatile memory of said backup server; and

,

acknowledging, in said primary server, said commit request if said mirroring is successfully confirmed.