Abstract:
A computer-implemented method and system for safe storing data is disclosed. A sending queue manager associated with a client computer transmits an asynchronous write of a transaction message containing data to a receiving queue manager associated with a transaction processing computer not collocated with the client computer. The receiving queue manager transmits a synchronous write of the transaction message to a remote queue manager associated with a remote disaster recovery computer to safe store the transaction message before it can be operated upon by the transaction processing computer.

Description:
FIELD OF THE INVENTION 
     The present invention relates generally to data management and, more particularly, to a method for safe storing data in a disaster recovery scenario. 
     BACKGROUND OF THE INVENTION 
     Transaction processing systems, particularly those employed in financial institutions, receive and process thousands of transactions a day. Each of these transactions may require operations to be performed on large amounts of data. As such, data management between communicating systems must be highly reliable. If the processing of a transaction fails due to an outage (e.g., a power loss or server failure), then it may be necessary to return a system to a known state of operation. The process of returning to a known state may be referred to as reconciliation. 
     It is desirable for transaction processing systems to be enabled with mechanisms for protecting against, as well as for recovering from, loss of data due to unexpected outages. Common mechanisms employed for data protection include, but are not limited to: (1) backup of data made to electronic storage media stored at regular intervals; (2) replication of data to an off-site location, which overcomes the need to restore the data (the corresponding systems then need only be restored or synchronized); and (3) high availability systems configured to keep both the data and system replicated off-site, enabling continuous access to systems and data. 
     In a disaster recovery context, replication of data may also be referred to as data mirroring. Depending on the technologies used, data mirroring may be performed synchronously, asynchronously, semi-synchronously, or point-in-time. As used herein, the term “asynchronous process” refers to a process that executes in the background and occurs as soon as it can in the background. As used herein, the term “synchronous process” refers to a process that executes directly in line with other processes and does not allow other processes to continue until one or more executable steps (e.g., a put or write) is completed. 
     Prior art data mirroring executed synchronously (i.e., using one or more synchronous processes) achieves a recovery point objective (RPO) of zero lost data, but may require unacceptably long execution time of a few minutes to perhaps several hours. Prior art data mirroring executed asynchronously (i.e., using one or more asynchronous processes) may achieve an RPO of just a few seconds, but does not guarantee zero data lost. 
     In high volume transaction processing systems, such as those used by financial institutions, an RPO of even just a few seconds is not acceptable, and may result in the loss of millions of dollars to clients and/or the transaction system provider. In addition, any remedial steps taken, depending upon the volume of data being received, should not add more than about a 50 to 100 milliseconds additional delay to complete a single message process. A person skilled in the art will recognize that a business can tolerate this time increase in the complete message cycle, since the time to transfer a single message is on the order of 250 milliseconds, mostly as a result of long distances between client and server. Also, a 50 to 100 milliseconds additional delay will not have any noticeable effect unless new messages arrive while the current message is still being processed on a specific channel. 
     Due to the smaller delays introduced by asynchronous mirroring methods, they are more frequently implemented. Unfortunately, prior art disaster recovery systems that employ asynchronous mirroring methods over long distances run the risk of data loss in the event of an outage. A disaster recovery declaration will result in a systems recovery to a point-in-time preceding the actual outage event. This results in a potential loss of data, which can be several seconds or minutes in duration and account for a plurality of transactions. In such circumstances, a receiving transaction processing system may complete a number of transactions and acknowledge their completion back to a requesting system before a disaster recovery system has safe stored all of the transactions. As used herein, the term “safe storing” refers to a transaction message that is received and stored in its original state prior to being processed. 
     Solutions are needed to account for and reconcile lost transaction messages, as well as to retrieve and process the same. Unfortunately, the widespread use of MQ network messaging technology with its “destructive” read of message traffic creates an environment whereby lost data cannot be re-sent by the sending systems or cannot be retrieved from message queues associated with the transaction processing system. Thus, a disaster recovery system may have no record of the most recent messages processed by the transaction processing system, thereby necessitating a difficult reconciliation process. This presents an unacceptable financial risk to businesses and requires a solution. 
     Accordingly, there exists a need for a method and system for safe storing transaction messages, data, and acknowledgements over long distances that permits minimal or no loss of data in a disaster recovery scenario. 
     SUMMARY OF THE INVENTION 
     The above-described problems are addressed and a technical solution is achieved in the art by providing a computer-implemented method and system for safe storing transaction messages in a disaster recovery scenario. A client computer sends transaction messages to a remotely located transaction processing computer. At substantially the same time, these transaction messages are also routed to a remotely located disaster recovery computer that is neither colocated with the sending computer or the transaction processing computer. 
     In a preferred embodiment, a sending queue manager associated with the client computer transmits an asynchronous write of a transaction message to a receiving queue manager associated with the transaction processing computer. Upon receipt, the receiving queue manager transmits a synchronous write of the transaction message to a remote disaster recovery queue manager associated with a remote disaster recovery computer to safe store the transaction message. Thereafter, the receiving queue manager transmits the same transaction message to a transaction processing queue manager where the transaction message is then processed by the transaction processing system, thereby preventing any possible loss of the message/data. 
     When the transaction message is received by the remote disaster recovery computer, the corresponding data is written to at least one memory component communicatively coupled to the remote disaster recovery computer at a remote recovery site. In a preferred embodiment, writing the information to the at least one memory component communicatively coupled to the remote disaster recovery computer may further comprise executing a synchronous PUT command. Additionally, when the transaction message is received by the transaction processing computer the corresponding data may also be written to at least one memory component communicatively coupled to the transaction processing computer at a primary site. In a preferred embodiment, writing the information to the at least one memory component communicatively coupled to the transaction processing computer at the primary site may further comprise executing an asynchronous PUT command. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The present invention will be more readily understood from the detailed description of exemplary embodiments presented below considered in conjunction with the attached drawings in which like reference numerals refer to similar elements and in which: 
         FIG. 1  illustrates a block diagram of an exemplary system for safe storing data in a disaster recovery scenario, in accordance with preferred embodiments of the present invention. 
         FIG. 2  is a detailed block diagram of software and hardware elements embodied in the system of  FIG. 1 , in accordance with preferred embodiments of the present invention. 
         FIG. 3  is a process flow diagram illustrating exemplary steps of a method for safe storing data in a disaster recovery scenario, in accordance with preferred embodiments of the present invention. 
         FIGS. 4A and 4B  are process flow diagrams illustrating the exemplary steps of  FIG. 3  in greater detail, in accordance with preferred embodiments of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     A client computer may not be colocated with a transaction processing computer. As a result, transaction messages may be transmitted between computers over a network. A computer may be any data processing device, such as a desktop computer, a laptop computer, a tablet computer, a mainframe computer, a server, a handheld device, a digital signal processor (DSP), an embedded processor, or any other device able to process data. Computers may be configured with one or more processors and may be communicatively connected to one or more non-transitory computer-readable media and one or more networks. The term “communicatively connected” is intended to include any type of communication may be conducted over a wireless or wired medium and includes, but is not limited to, OTA (over-the-air transmission, ATSC, DVB-T), packet-switched networks (TCP/IP, e.g., the Internet), satellite (microwave, MPEG transport stream or IP), direct broadcast satellite, analog cable transmission systems (RF), and digital video transmission systems (ATSC, HD-SDI, HDMI, DVI, VGA), or any other applicable communication-enabled mechanism. 
     The one or more computer-readable media may be used for storing the instructions to be executed by the one or more processors, including an operating system, such as the Windows™ UNIX™, OSX™, or the Linux operating system. The computer readable media may further be used for the storing and retrieval of data in one or more databases. The computer readable media may include a combination of volatile memory, such as RAM memory, and non-volatile memory, such as flash memory, optical disk(s), and/or hard disk(s). 
     In  FIG. 1 , an exemplary system  10  for safe storing data in a disaster recovery scenario is provided.  FIG. 2  provides additional detail with respect to the components (hardware and software) embodied in system  10  illustrated in  FIG. 1 . In system  10 , one or more remote client sites  12  may be provided and communicatively connected to a network  14 . Each of remote client sites  12  may include at least one client computer  16  and an associated memory  18 . Data may be transmitted over network  14 . Messages may be sent over network  14  via one of several proprietary and/or non-proprietary messaging protocols including, but not limited to, SNA links, MQ links or file transfers. 
     In a preferred embodiment, the transmitted messages may be transaction messages. The transaction messages may include, but are not limited to, MQ messages. Each of the transaction messages, in turn, may include, but are not limited to, one or more executable methods or commands, data elements or structures associated with the commands, acknowledgement messages, negative acknowledgement messages, function calls, or any other applicable arrangement of data. 
     Client computer  16  may be a plurality of servers or, alternatively, a single server. Memory  18  may be a plurality of volatile and non-volatile memory devices. As illustrated in  FIG. 2 , client computer  16  may comprise a sending queue manager  20  and a client application  23 . Sending queue manager  20  may be configured to manage one or more message processing queues  22   a - 22   n , provided in memory  18 , received from client application  23 . Sending queue manager  20  may be further configured to transmit transaction messages  24   a - 24   n  to a primary site  26 . 
     Transaction messages  24   a - 24   n  are received at primary site  26  and processed by at least one programmed computer  28  and associated memory  30 , as illustrated in  FIG. 1 . Computer  28  may be a plurality of servers or a single server. Memory  30  may be a plurality of volatile and non-volatile memory devices. In a preferred embodiment, computer  28  may comprise a message routing server  32 , as illustrated in  FIG. 2 , configured to route transaction messages  24   a - 24   n  to a production server  34 , which may be located at primary site  26  and/or a remote recovery site  36 . Message routing server  32  may be configured with a receiving queue manager  38  for managing one or more message processing queues  40   a - 40   n . Receiving queue manager  38  receives transaction messages  24   a - 24   n  and transmits the same to message processing queues  40   a - 40   n , which are then relaid to a production queue manager  42  in production server  34 . Production queue manager  42 , via a production system application  43 , is configured to operate on transaction messages  24   a - 24   n  and provide corresponding acknowledgement messages  44   a - 44   n  back to client computer  16 . Transaction messages  24   a - 24   n , along with associated original/processed data and acknowledgement messages  44   a - 44   n , may be stored in one or more databases  48   a - 48   n.    
     Computer  28  is also configured to transmit the Transaction messages  24   a - 24   n  received by computer  28  at primary site  26  may also be transmitted to at least one programmed computer  50  and associated memory  52 , over network  14 , located at remote recovery site  36 . In a preferred embodiment, each of client sites  12 , primary site  26 , and remote recovery site  36  are not colocated. 
     Similar to computer  28  at primary site  26 , computer  50  may be a plurality of servers or a single server. Similarly, memory  52  may be a plurality of volatile and non-volatile memory devices. In a preferred embodiment, computer  50  may comprise a message routing server  54 , as illustrated in  FIG. 2 , configured to route transaction messages  24   a ′- 24   n ′ to a disaster recovery server  56 , which is configured to mirror the processing of transaction messages  24   a ′- 24   n ′ in production server  34 . Message routing server  54  may be configured with a remote recovery queue manager  58  for managing one or more message processing queues  60   a - 60   n . Remote queue manager  58  receives transaction messages  24   a ′- 24   n ′ and transmits the same to message processing queues  60   a - 60   n , which are then transmitted to a production queue manager  62  in disaster recovery server  56 . Production queue manager  62  is configured to operate, via a production system application  63 , on transaction messages  24   a ′- 24   n ′. Transaction messages  24   a ′- 24   n ′, along with associated original/processed data, may be stored in one or more non-volatile databases  64   a - 64   n.    
     In  FIG. 3 , a process flow  300  is provided to illustrate the steps for safe storing data in a disaster recovery scenario. Process flow  300  is initiated when client computer  16  transmits data, at step S 1 , over the network  14  to primary site  26 . Data is received, at step S 2 , by computer  28  at primary site  26 . In a preferred embodiment, client computer  16  asynchronously writes (i.e., transmits) data to computer  28 . Before data is committed to memory  30  at primary site  26 , computer  28  synchronously writes, at step S 3 , the data to computer  50  at remote recovery site  36  via network  14 . While data is being synchronously written to recovery computer  50 , no other processing may be initiated by computer  28  at primary site  26  before the data is processed by computer  50  at remote recovery site  36 . Computer  50  stores the data in memory  52 . After the data is stored in memory  52 , the data is processed, at step S 4 , by computer  28  and stored in memory  30  at primary site  26 . Computer  28  may additionally transmit, at step S 5 , an acknowledgement message back to client computer  16  at remote client site  12  over network  14 . 
       FIGS. 4A and 4B  depict a process flow  400  illustrating steps S 1 -S 5  of  FIG. 3  in greater detail. Similar to process flow  300 , process flow  400  is initiated by client computer  16  sending data to computer  28  at primary site  26 . Referring to  FIGS. 4A-4B , sending queue manager  20  associated with client computer  16  at the remote client site  12  retrieves, at step S 1   a , a transaction message (comprising data)  24   a  from processing queue  22   a  located in memory  18 . Upon retrieving a transaction message, sending queue manager  20  transmits, at step S 1   b , transaction message  24   a  over network  14  to primary site  26 . More specifically, client computer  16  asynchronously writes (i.e., transmits) transaction message  24   a  to processing queue  40   a  via receiving queue manager  38  of computer  28 . For example, transaction message  24   a  may be asynchronously written to processing queues  40   a  using an asynchronous PUT command. 
     When transaction message  24   a  is received, at step S 2   a , by receiving queue manager  38 , transaction message  24   a  may be temporarily stored, at step S 2   b , in processing queue  40   a . Receiving queue manager  38  may then retrieve, at step S 3   a , transaction message  24   a  from processing queue  40   a  and, because messages may be destructively read from queues, receiving queue manager  38  may further make a copy of transaction message  24   a  (hereinafter referred to as transaction message  24   a ′). Then receiving queue manager  38  synchronously writes, at step S 3   b  transaction message  24   a ′ to processing queue  60   a  via remote recovery queue manager  58  at remote recovery site  36  over network  14 . For example, transaction message  24   a ′ is synchronously written to message processing queue  60   a  using a synchronous PUT command. 
     After remote queue manager  58  receives, at step S 3   c , transaction message  24   a ′, it may then temporarily store the message in processing queue  60   a . Remote queue manager  58  retrieves, at step S 3   d , transaction message  24   a ′ from processing queue  60   a  and, similar to processing queue  40   a  at primary site  26 , remote queue manager  58  may make a copy of transaction message  24   a ′ (herein after referred to as the “transaction message  24   a ”). 
     Remote queue manager  58  may then transmit, at step S 3   e , transaction messages  24   a ″ to production queue manager  62  in disaster recovery server  56 . Production queue manager  62  may then operate (i.e., completes the transaction), at step S 3   f , via recovery system application  63  on transaction message  24   a ″. The processed transaction message  24   a ″ may have associated data. As a result, production queue manager  62  may store, at step S 3   g , transaction message  24 ″, along with associated original/processed data, in database  64   a.    
     Once the synchronous write of transaction message  24   a ′ to remote recovery site  36  has been completed, transaction message  24   a ′ may be further processed by message routing server  32  at primary site  26 . Receiving queue manager  38  of message routing server  32  transmits, at step S 4   a , transaction message  24   a ′ to production queue manager  42  in production server  34 . Production queue manager  42  operates (i.e., completes the transaction), at step S 4   b , on transaction message  24   a ′ via production system application  43 . The processed transaction message  24   a ′ may have associated data. As a result, production queue manager  42  may store, at step S 4   c , transaction message  24 ′, along with associated original/processed data and acknowledgement message  44   a , in database  48   a.    
     Once data has been written to database  48   a , receiving queue manager  38  may then send, at step S 5 , acknowledgement message  44   a  back to sending queue manager  20  associated with client computer  16  at remote client site  12  over network  14 . 
     It is to be understood that the exemplary embodiments are merely illustrative of the invention and that many variations of the above-described embodiments may be devised by one skilled in the art without departing from the scope of the invention. It is therefore intended that all such variations be included within the scope of the following claims and their equivalents.