CA2221661A1 - Transaction roll forward - Google Patents
Transaction roll forward Download PDFInfo
- Publication number
- CA2221661A1 CA2221661A1 CA 2221661 CA2221661A CA2221661A1 CA 2221661 A1 CA2221661 A1 CA 2221661A1 CA 2221661 CA2221661 CA 2221661 CA 2221661 A CA2221661 A CA 2221661A CA 2221661 A1 CA2221661 A1 CA 2221661A1
- Authority
- CA
- Canada
- Prior art keywords
- node
- transaction
- application
- log
- roll forward
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0859—Retrieval of network configuration; Tracking network configuration history by keeping history of different configuration generations or by rolling back to previous configuration versions
- H04L41/0863—Retrieval of network configuration; Tracking network configuration history by keeping history of different configuration generations or by rolling back to previous configuration versions by rolling back to previous configuration versions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/02—Standardisation; Integration
- H04L41/0213—Standardised network management protocols, e.g. simple network management protocol [SNMP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/085—Retrieval of network configuration; Tracking network configuration history
- H04L41/0853—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information
- H04L41/0856—Retrieval of network configuration; Tracking network configuration history by actively collecting configuration information or by backing up configuration information by backing up or archiving configuration information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
- H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
- H04Q11/0478—Provisions for broadband connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q3/00—Selecting arrangements
- H04Q3/0016—Arrangements providing connection between exchanges
- H04Q3/0062—Provisions for network management
- H04Q3/0095—Specification, development or application of network management software, e.g. software re-use
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
- G06F11/3414—Workload generation, e.g. scripts, playback
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/87—Monitoring of transactions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5629—Admission control
- H04L2012/563—Signalling, e.g. protocols, reference model
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
In a method of monitoring transactions in a network application, a transaction log is maintained at a node, and a separate log is maintained. A playback is implemented which relies on the application to replay the original knowledge context of the transaction, and if this replayed mechanism fails, a transaction rollback mechanism is invoked to restore both the application and the node to a mutually consistent state.
Description
TRANSACTION ROLL FORWARD
This invention relates to a method of monilo~ g network transactions, for example, in a wide area network controlled by network management software.
The Telecommunications Management Network (TMN) model, developed by the Tnt~rn~tional Telecommunications Union (ITU), defines three areas: Element Management, Network Management and Service Management.
The Element Manager Layer controls the information exchange between network elements or groups of network elements. Functions within this layer co~ nul,icate with the Network Management Layer by relaying element status and performance to a network management system (NMS).
The Network Management Layer in the TMN Model covers the end-to-end management of an entire network. It contains an overview of the network and knows how elements relate to each other. Focusing on network usage, traffic patterns, bandwidth availability and performance monitoring, the Network Management Layer interacts with the Service Management Layer by exch~n~in~ network status information for customer and service data. Responsibilities of the Network Management Layer include: controlling and coor~lin~ting the network view of all network elements within its domain, provisioning and modifying network capabilities for customer-service support, m~ Ail-il-g statistical, log and other data about the network and interacting with the Service Management, Layer on performance, usage and availability.
The Service Management Layer is the service provider's first point of contact with customers for all service transactions, including service requests and fault reporting, interaction with other service providers, and m~ ining statistical data and interaction between services.
The present "state of the art" transaction roll-forward on a network element is to log all node (network element) affecting transactions from the last node backup. In the event of a failure all logs are re-applied to the node. A major shortcoming to this approach is the fact that the node has a limited context. The node logs only incorporates node affecting transaction not necessary element or network management transactions.
For example an element management transaction "X" may be composed of node transactions a, b and c. In the event of a failure the node will try and replay a, b and c. If a fails, b and c should not be applied because they are part of X which needs to be fully applied or not at all. The node logs have no knowledge of X. The result will be that the node and the applications supporting the node are in a inconsistent state.
An object of the invention is to overcome this problem.
According to the present invention there is provided a method of monitoring transactions in a network application, wherein a transaction log is m~int~ined at a node, a separate log is m~int~ined, a playback is implemented which relies on the application to replay the original knowledge context of the transaction, and if this replayed mechanism fails, a kansaction rollback mech~ni~m is invoked to restore both the application and the node to a m~ lly consistent state.
By implementing transaction logging our solution now m~int~in~ a log similar to the nodes. We then implement a playback which relies on the application to replay the original knowledge of the context of the transaction. If this "replayed" transaction fails than the applications transaction rollback mech~ni.cm is invoked and restores both the application and the node to a mllt~1~11y consistent state.
By implementing centralized transaction logging our solution now m~int~in.~ a log similar to the nodes. We then implement a playback which relies on the application to replay the original knowledge of the context of the transaction. If this "replayed"
transaction fails than the applications transaction rollback mech~ni~m is invoked and restores both the application and the node to a mutually con~i~ttq.nt state. When we implement a playback we also ensure that the log is played back in a synchronized fashion to ensure node and application consistency.
The invention can be applied to any situation where a node is modified by a multi stage transaction arid may at a later time need to be restored.
The invention will now be described in more detail, by way of example only, withreference to the acco,l,pallyi,lg drawings, in which:-Figure 1 is an overview of an ATM network to which the inventive system may beapplied;
Figure 2 is an overview of a system in accordance with the invention;
Figure 3 shows a roll forward of transactions;
Figure 4 shows a cross connect creation; and Figure 5 shows a cross connect roll forward.
Figure 1 shows the general architecture of a system to which the invention is applicable. An ATM network manager is managed by a commander 2 implementing the present invention, which communicates with the network manager via a protocol Qs, which is a published interf~ce from Newbridge Networks Corporation.
Roll forward is required on a node after a catastrophe. The major assumptions behind this design are:
1. The customer has a failing switch
This invention relates to a method of monilo~ g network transactions, for example, in a wide area network controlled by network management software.
The Telecommunications Management Network (TMN) model, developed by the Tnt~rn~tional Telecommunications Union (ITU), defines three areas: Element Management, Network Management and Service Management.
The Element Manager Layer controls the information exchange between network elements or groups of network elements. Functions within this layer co~ nul,icate with the Network Management Layer by relaying element status and performance to a network management system (NMS).
The Network Management Layer in the TMN Model covers the end-to-end management of an entire network. It contains an overview of the network and knows how elements relate to each other. Focusing on network usage, traffic patterns, bandwidth availability and performance monitoring, the Network Management Layer interacts with the Service Management Layer by exch~n~in~ network status information for customer and service data. Responsibilities of the Network Management Layer include: controlling and coor~lin~ting the network view of all network elements within its domain, provisioning and modifying network capabilities for customer-service support, m~ Ail-il-g statistical, log and other data about the network and interacting with the Service Management, Layer on performance, usage and availability.
The Service Management Layer is the service provider's first point of contact with customers for all service transactions, including service requests and fault reporting, interaction with other service providers, and m~ ining statistical data and interaction between services.
The present "state of the art" transaction roll-forward on a network element is to log all node (network element) affecting transactions from the last node backup. In the event of a failure all logs are re-applied to the node. A major shortcoming to this approach is the fact that the node has a limited context. The node logs only incorporates node affecting transaction not necessary element or network management transactions.
For example an element management transaction "X" may be composed of node transactions a, b and c. In the event of a failure the node will try and replay a, b and c. If a fails, b and c should not be applied because they are part of X which needs to be fully applied or not at all. The node logs have no knowledge of X. The result will be that the node and the applications supporting the node are in a inconsistent state.
An object of the invention is to overcome this problem.
According to the present invention there is provided a method of monitoring transactions in a network application, wherein a transaction log is m~int~ined at a node, a separate log is m~int~ined, a playback is implemented which relies on the application to replay the original knowledge context of the transaction, and if this replayed mechanism fails, a kansaction rollback mech~ni~m is invoked to restore both the application and the node to a m~ lly consistent state.
By implementing transaction logging our solution now m~int~in~ a log similar to the nodes. We then implement a playback which relies on the application to replay the original knowledge of the context of the transaction. If this "replayed" transaction fails than the applications transaction rollback mech~ni.cm is invoked and restores both the application and the node to a mllt~1~11y consistent state.
By implementing centralized transaction logging our solution now m~int~in.~ a log similar to the nodes. We then implement a playback which relies on the application to replay the original knowledge of the context of the transaction. If this "replayed"
transaction fails than the applications transaction rollback mech~ni~m is invoked and restores both the application and the node to a mutually con~i~ttq.nt state. When we implement a playback we also ensure that the log is played back in a synchronized fashion to ensure node and application consistency.
The invention can be applied to any situation where a node is modified by a multi stage transaction arid may at a later time need to be restored.
The invention will now be described in more detail, by way of example only, withreference to the acco,l,pallyi,lg drawings, in which:-Figure 1 is an overview of an ATM network to which the inventive system may beapplied;
Figure 2 is an overview of a system in accordance with the invention;
Figure 3 shows a roll forward of transactions;
Figure 4 shows a cross connect creation; and Figure 5 shows a cross connect roll forward.
Figure 1 shows the general architecture of a system to which the invention is applicable. An ATM network manager is managed by a commander 2 implementing the present invention, which communicates with the network manager via a protocol Qs, which is a published interf~ce from Newbridge Networks Corporation.
Roll forward is required on a node after a catastrophe. The major assumptions behind this design are:
1. The customer has a failing switch
2. Retllrning as many components of the switch to service as fast as possible is by far the most important task.
3. The switch must be in a con~i.ct~nt state at the end of the recovery to reduce requirement for manual intervention.
4. A clear log of failed RollForward transactions must be provided to the customer.
This feature is inten-led for use by customers when a catastrophic event has caused the EWSX switch to require a reboot from a backup. This feature enables lling the Node to the state it was just before the catastrophe by performing a roll forward of transactions sent to the Node since the last backup.
The ATM-C Roll Forward is a product which supports the Siemens EWSXpress V3 ATM switch and applications. It provides a mechanism for the recover,v of the Node from a catastrophe via the roll fol ~d of transactions performed on the Node since a backup was performed.
A central process on the ATMC is receiving messages cont~ining information on all transactions performed on the Node. The feature logs the transactions in separate file for each node. Applications, such as CR, SS7 etc. are using the ATMC API Loggingfunction to send the logging messages to the proper ATMC controlling the Node. It is assumed that only transactions that are successfully applied to the node are logged. This implies that the logging of transactions must be done by the application only at the end of the transaction. The transaction itself contains a time stamp indicating when it has started.
This information is used for the sequence of roll forward.
The Roll Forward of transactions enables the restoration of the Node Database toits state from before a catastrophic failure. Proper recovery of all the data requires synchronization between all the applications controlling the Node. This feature controls the sequence at which transaction that were applied to the node before the crash are being send to the node. This feature reads the log file generated by the logging mech~m~m.
The Logging and Roll Forward mech~ni~m of the ATMC require that all applications that are acting on the Node use both of the following interfaces:
~ Logging interface to log all changes to the Node ~ Roll Forward ~nt~ ce - To enable roll forward of all actions performed on the node.
The logging interface is part of the CKATMCAPI class and contains the following function void ATMCClient ~ (ATMCAddressType Atmc, 11 Address of the ATMC Used for logging char ~NodeDn, 11 The DN of the Node for that operation time t StartTime, 11 The time at which the operation started.
char ~Applirs~i''n 11 Application Name char ~Description, 11 String 1~ r . ' ' ~ of the action - used for manual roll forward unsigned long DataSize, 11 Size of the data to be logged for the event void ~Data, 11 The transaction data long Delay = 0,11 Specify amount of time in " - ' to wait before executing next command int ~ , ' = I 11 Indicates if the Roll Forward ' should wait for completion of this command before sending the next one.
);
~pplication name: Is a string used for identification of the application logging the transaction. This is displayed to the user during the Manual roll forward (See section Error! Reference source not found.) and as an identifier to the roll forward mech~ni~m of the application performing the transaction during the roll forward.
Description: A user readable string cont~ining all the information used by the transaction. This information allows the user to screen out transactions during roll fol vv~d.
Data: This is the binary data used for roll fol ~v~d. This information is send back to the application during roll forward.
DataSize: The size of the data in bytes.
WaitCompletion: See below.
During roll forward the application will send roll forward request to all the applications that logged actions.
The following pseudo code illustrates a typical applications written for roll forward:
Fd = RollForwardOpen () for ever {
select on fd and others if (message on fd) { 1I E.G. Roll Forward RollForwardGetTransaction Process Transaction RollForwardSendConfirm~tion } else { 1I Message from other sources something else }
Following are the int~rf~ces for roll forward:
int RollForwardOpen () This interface opens a socket connection that accepts messages from the Roll fo~ rd Application. The return value is a file descriptor that can be use in a select statement.
int RollForwardHasTransaction () This application returns 1 if there is an action waiting for roll fol ~/v~d in the message queue. 0 is returned if there are no messages in the queue. This is not an indication that the roll forward is done see Error! Reference source not found.Error!
Reference source not found.
int RollForwardGetTransaction (unsigned short &DataSize, void * &Data, int &NeedConfirm~tion) This enables the application to get the next action from the roll forward interface.
The first parameter is the size of the logged data. The second parameter a void pointer to the logged Data. The third parameter indicates whether the roll forward process is going to wait for a completion message from the application, when it is set to 1 the application must use RollForwardSendConfirm~tion once it is safe to roll forward the next transaction. This is set to 1 only if the WaitCompletion flag was set to 1 when the application has logged the transaction.
The return value of this command is: 0 - Fail 1 - Data Available 2 - Done with roll forward void RollForwardSendConfirm~tion (int Status = 1) This comm~r d must be used if the WaitCompletion Flag was set to 1 in the RollForwardGetAction request. Use this function to indicate to the roll forward mechanism that the application is ready to receive the next transaction. This function is used only by applications that set the WaitCompletion flag in the logging record.
When the Status flag is set to 0 the RollForward mech~ni~m assumes that the transaction has failed and will generate the a~propliate log to the customer.
On startup the roll forward application will get the information of the node requiring roll fol ~vald, the time at which the last backup has been performed. (This feature assumes that the backup generation was already applied to the node). Then, It will scan the log file and determine the list of applications that were active during the time from the backup.
The roll forward application will attempt to connect to all the applications obtained in the previous step. If any of the application fails to respond the roll forward application plo~ the user to start the application m~nll~lly on the ~pplopl;ate m~chine.
As long as not all transactions from the log have been rolled forward the roll forward application will:
~ send transactions to the a~plopl;ate application ~ Wait for the proper reply.
During manual roll forward the RollForward application prompts the user before each transaction is send to the other applications for execution.
As long as not all actions from the log have been rolled forward the RollForwardapplication will:
~ Prompt the user for the execution of the next command ~ Abort or skip comm~ntl as per user input or ~ send actions to the al)propliate application ~ Wait for the proper reply.
See Figure 2 above The Roll Forward application will send a Finish message to all the other applications.
It is assumed that all logged operations were:
Authenticated - That during the initial invocation of the transaction the application has verified that the user have the adequate cre~l~nti~l~ that enable him to carry on the specific operation.
~uccessful - During the roll forward of the comm~ncl~ it is also assumed that all comm~n-ls logged through the logging mech~ni~m were successfully applied to the Switch.
Error recovery during roll forward is via the existing transaction roll backward of the applications. Transaction roll backward is designed as part of standard transaction h~n~11ing. During roll fo~ ud the built in Roll Backward of transactions should work as during normal operation. Since roll fol ~v~rd is done for transactions that weresuccessfully applied to the node, it is anticipated that this mech~ni~m will rarely be invoked. However, in the case of hardware failure, during roll forward, of one of the modules on the Node a transaction may abort. In this case the transaction should behave the same way as it would under normal conditions - that is roll backward. This will leave the Switch in the most con~i~tçnt way possible. Logs indicating the failure will appear in a standard log. Since we do not necessarily have a GUI connected to the applications the SendConfirm~tion message to the RollForward mechanism should indicate the failure so that the Roll Forward mech~nicm can generate additional required logs.
It is known that this mech~ni~m not manage to completely restore the Node to itsoriginal condition under the following conditions:
1. A race condition between two applications or transactions while setting an attribute for the same object. In this case there is no way to determine which application will be the last to set the attribute, and therefor to assure proper operation.
2. There is a physical problem with one of the components on the Switch.
The following applications are known to be using the logging and roll forward API stubs at the release 2 time frame:
~ ATMC base.
~ Call Routing ~ SS7 ~ Q3PS
. Autocraft The following example is an example of creation of a cross connect. This type ofoperation is a very typical one on the ATMC and at any given time we might have multiple cross connect transactions in operation.
As can be seen from the above figures, using cross Q3 roll forward will result in reversing the state of the two object. That is the connection represented by Object 1 will be inactive while the connection represented by Object 2 is going to be active. This is in contrast to the original state of the connections where the connection represented by Object 1 was active and the connection represented by object 2 was inactive.
Q3 logging at the object level is the original proposal prepared for CR/SS7. In this design the application is logging the Q3 objects just before they send the comm~n(l to the Node. Using Vertel this implies that before sending comm~n(lc. to the node the application can translate the Vertel object to a BER representation using the Vertel "Ber_Encode"
template then send the information to the logging mechanism using a function as follows:
void ATMCClient:: LogOperations (ATMCAddressType Atmc, 11 Address of the ATMC Used for logging char ~NodeDn, 11 The DN of the Node for that operation time_t StartTime, 11 The time at which the operation started.
char ~pplicq~inn 11 Application Name char ~Description, 11 String l.r. of the action - used for manual roll forward long DataSi~, 11 Si~ of the data to be logged for the event void ~Data, 11 The BER of the transaction object long Delay = 0, 11 Specify amount of time in ' to wait before executing next command int W ~ p' = I 11 Indicates if the Roll Forward - ' should wait for completion of this command before sending the next one.
); .
During the roll forward of the transaction the Roll Forward agent will perform similar tasks to the ones described above. The only difference between is that instead of sending the Q3 actions to the applications for execution the BER data of the Q3 actions is converted to a Vertel Object representing the Q3 comm~n~l (IJsing features of the Vertel Stack T.B.D) and the action is than sent to the Node for execution. Q3 is a standards based intP~ce for m~n~ging network elements. The Siemens EWSX V3 is managed via a Q3 interface.
Logging at the Socket level is similar to the design described in the previous section, except that instead of the application calling a special function for the purpose of logging of the col "~ n~l~ the data is intercepted and logged at the MP 120 Daemon. This design has the following problems:
Requires modification ofthe MP120 (Vertel).
~ Does not support any other stack such as the one used by Q3PS.
~ Selection of 'actions' during the roll forward is very hard since there is no information as for the generating application and user (Official requirement).
This feature is inten-led for use by customers when a catastrophic event has caused the EWSX switch to require a reboot from a backup. This feature enables lling the Node to the state it was just before the catastrophe by performing a roll forward of transactions sent to the Node since the last backup.
The ATM-C Roll Forward is a product which supports the Siemens EWSXpress V3 ATM switch and applications. It provides a mechanism for the recover,v of the Node from a catastrophe via the roll fol ~d of transactions performed on the Node since a backup was performed.
A central process on the ATMC is receiving messages cont~ining information on all transactions performed on the Node. The feature logs the transactions in separate file for each node. Applications, such as CR, SS7 etc. are using the ATMC API Loggingfunction to send the logging messages to the proper ATMC controlling the Node. It is assumed that only transactions that are successfully applied to the node are logged. This implies that the logging of transactions must be done by the application only at the end of the transaction. The transaction itself contains a time stamp indicating when it has started.
This information is used for the sequence of roll forward.
The Roll Forward of transactions enables the restoration of the Node Database toits state from before a catastrophic failure. Proper recovery of all the data requires synchronization between all the applications controlling the Node. This feature controls the sequence at which transaction that were applied to the node before the crash are being send to the node. This feature reads the log file generated by the logging mech~m~m.
The Logging and Roll Forward mech~ni~m of the ATMC require that all applications that are acting on the Node use both of the following interfaces:
~ Logging interface to log all changes to the Node ~ Roll Forward ~nt~ ce - To enable roll forward of all actions performed on the node.
The logging interface is part of the CKATMCAPI class and contains the following function void ATMCClient ~ (ATMCAddressType Atmc, 11 Address of the ATMC Used for logging char ~NodeDn, 11 The DN of the Node for that operation time t StartTime, 11 The time at which the operation started.
char ~Applirs~i''n 11 Application Name char ~Description, 11 String 1~ r . ' ' ~ of the action - used for manual roll forward unsigned long DataSize, 11 Size of the data to be logged for the event void ~Data, 11 The transaction data long Delay = 0,11 Specify amount of time in " - ' to wait before executing next command int ~ , ' = I 11 Indicates if the Roll Forward ' should wait for completion of this command before sending the next one.
);
~pplication name: Is a string used for identification of the application logging the transaction. This is displayed to the user during the Manual roll forward (See section Error! Reference source not found.) and as an identifier to the roll forward mech~ni~m of the application performing the transaction during the roll forward.
Description: A user readable string cont~ining all the information used by the transaction. This information allows the user to screen out transactions during roll fol vv~d.
Data: This is the binary data used for roll fol ~v~d. This information is send back to the application during roll forward.
DataSize: The size of the data in bytes.
WaitCompletion: See below.
During roll forward the application will send roll forward request to all the applications that logged actions.
The following pseudo code illustrates a typical applications written for roll forward:
Fd = RollForwardOpen () for ever {
select on fd and others if (message on fd) { 1I E.G. Roll Forward RollForwardGetTransaction Process Transaction RollForwardSendConfirm~tion } else { 1I Message from other sources something else }
Following are the int~rf~ces for roll forward:
int RollForwardOpen () This interface opens a socket connection that accepts messages from the Roll fo~ rd Application. The return value is a file descriptor that can be use in a select statement.
int RollForwardHasTransaction () This application returns 1 if there is an action waiting for roll fol ~/v~d in the message queue. 0 is returned if there are no messages in the queue. This is not an indication that the roll forward is done see Error! Reference source not found.Error!
Reference source not found.
int RollForwardGetTransaction (unsigned short &DataSize, void * &Data, int &NeedConfirm~tion) This enables the application to get the next action from the roll forward interface.
The first parameter is the size of the logged data. The second parameter a void pointer to the logged Data. The third parameter indicates whether the roll forward process is going to wait for a completion message from the application, when it is set to 1 the application must use RollForwardSendConfirm~tion once it is safe to roll forward the next transaction. This is set to 1 only if the WaitCompletion flag was set to 1 when the application has logged the transaction.
The return value of this command is: 0 - Fail 1 - Data Available 2 - Done with roll forward void RollForwardSendConfirm~tion (int Status = 1) This comm~r d must be used if the WaitCompletion Flag was set to 1 in the RollForwardGetAction request. Use this function to indicate to the roll forward mechanism that the application is ready to receive the next transaction. This function is used only by applications that set the WaitCompletion flag in the logging record.
When the Status flag is set to 0 the RollForward mech~ni~m assumes that the transaction has failed and will generate the a~propliate log to the customer.
On startup the roll forward application will get the information of the node requiring roll fol ~vald, the time at which the last backup has been performed. (This feature assumes that the backup generation was already applied to the node). Then, It will scan the log file and determine the list of applications that were active during the time from the backup.
The roll forward application will attempt to connect to all the applications obtained in the previous step. If any of the application fails to respond the roll forward application plo~ the user to start the application m~nll~lly on the ~pplopl;ate m~chine.
As long as not all transactions from the log have been rolled forward the roll forward application will:
~ send transactions to the a~plopl;ate application ~ Wait for the proper reply.
During manual roll forward the RollForward application prompts the user before each transaction is send to the other applications for execution.
As long as not all actions from the log have been rolled forward the RollForwardapplication will:
~ Prompt the user for the execution of the next command ~ Abort or skip comm~ntl as per user input or ~ send actions to the al)propliate application ~ Wait for the proper reply.
See Figure 2 above The Roll Forward application will send a Finish message to all the other applications.
It is assumed that all logged operations were:
Authenticated - That during the initial invocation of the transaction the application has verified that the user have the adequate cre~l~nti~l~ that enable him to carry on the specific operation.
~uccessful - During the roll forward of the comm~ncl~ it is also assumed that all comm~n-ls logged through the logging mech~ni~m were successfully applied to the Switch.
Error recovery during roll forward is via the existing transaction roll backward of the applications. Transaction roll backward is designed as part of standard transaction h~n~11ing. During roll fo~ ud the built in Roll Backward of transactions should work as during normal operation. Since roll fol ~v~rd is done for transactions that weresuccessfully applied to the node, it is anticipated that this mech~ni~m will rarely be invoked. However, in the case of hardware failure, during roll forward, of one of the modules on the Node a transaction may abort. In this case the transaction should behave the same way as it would under normal conditions - that is roll backward. This will leave the Switch in the most con~i~tçnt way possible. Logs indicating the failure will appear in a standard log. Since we do not necessarily have a GUI connected to the applications the SendConfirm~tion message to the RollForward mechanism should indicate the failure so that the Roll Forward mech~nicm can generate additional required logs.
It is known that this mech~ni~m not manage to completely restore the Node to itsoriginal condition under the following conditions:
1. A race condition between two applications or transactions while setting an attribute for the same object. In this case there is no way to determine which application will be the last to set the attribute, and therefor to assure proper operation.
2. There is a physical problem with one of the components on the Switch.
The following applications are known to be using the logging and roll forward API stubs at the release 2 time frame:
~ ATMC base.
~ Call Routing ~ SS7 ~ Q3PS
. Autocraft The following example is an example of creation of a cross connect. This type ofoperation is a very typical one on the ATMC and at any given time we might have multiple cross connect transactions in operation.
As can be seen from the above figures, using cross Q3 roll forward will result in reversing the state of the two object. That is the connection represented by Object 1 will be inactive while the connection represented by Object 2 is going to be active. This is in contrast to the original state of the connections where the connection represented by Object 1 was active and the connection represented by object 2 was inactive.
Q3 logging at the object level is the original proposal prepared for CR/SS7. In this design the application is logging the Q3 objects just before they send the comm~n(l to the Node. Using Vertel this implies that before sending comm~n(lc. to the node the application can translate the Vertel object to a BER representation using the Vertel "Ber_Encode"
template then send the information to the logging mechanism using a function as follows:
void ATMCClient:: LogOperations (ATMCAddressType Atmc, 11 Address of the ATMC Used for logging char ~NodeDn, 11 The DN of the Node for that operation time_t StartTime, 11 The time at which the operation started.
char ~pplicq~inn 11 Application Name char ~Description, 11 String l.r. of the action - used for manual roll forward long DataSi~, 11 Si~ of the data to be logged for the event void ~Data, 11 The BER of the transaction object long Delay = 0, 11 Specify amount of time in ' to wait before executing next command int W ~ p' = I 11 Indicates if the Roll Forward - ' should wait for completion of this command before sending the next one.
); .
During the roll forward of the transaction the Roll Forward agent will perform similar tasks to the ones described above. The only difference between is that instead of sending the Q3 actions to the applications for execution the BER data of the Q3 actions is converted to a Vertel Object representing the Q3 comm~n~l (IJsing features of the Vertel Stack T.B.D) and the action is than sent to the Node for execution. Q3 is a standards based intP~ce for m~n~ging network elements. The Siemens EWSX V3 is managed via a Q3 interface.
Logging at the Socket level is similar to the design described in the previous section, except that instead of the application calling a special function for the purpose of logging of the col "~ n~l~ the data is intercepted and logged at the MP 120 Daemon. This design has the following problems:
Requires modification ofthe MP120 (Vertel).
~ Does not support any other stack such as the one used by Q3PS.
~ Selection of 'actions' during the roll forward is very hard since there is no information as for the generating application and user (Official requirement).
Claims (2)
PROPERTY OR PRIVILEGE IS CLAIMED ARE DEFINED AS FOLLOWS:
1. A method of monitoring transactions in a network application, wherein a transaction log is maintained at a node, a separate log is maintained, a playback is implemented which relies on the application to replay the original knowledge context of the transaction, and if this replayed mechanism fails, a transaction rollback mechanism is invoked to restore both the application and the node to a mutually consistent state.
2. A method as claimed in claim 1, wherein a centralized log is maintained similar to the log at the nodes, and when a playback is implemented the log is played back in a synchronized manner to ensure node and application consistency.
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2221661 CA2221661A1 (en) | 1997-11-20 | 1997-11-20 | Transaction roll forward |
| PCT/CA1998/001074 WO1999027750A1 (en) | 1997-11-20 | 1998-11-19 | Transaction roll forward |
| EP98955287A EP1031255A1 (en) | 1997-11-20 | 1998-11-19 | Transaction roll forward |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2221661 CA2221661A1 (en) | 1997-11-20 | 1997-11-20 | Transaction roll forward |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2221661A1 true CA2221661A1 (en) | 1999-05-20 |
Family
ID=4161785
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2221661 Abandoned CA2221661A1 (en) | 1997-11-20 | 1997-11-20 | Transaction roll forward |
Country Status (3)
| Country | Link |
|---|---|
| EP (1) | EP1031255A1 (en) |
| CA (1) | CA2221661A1 (en) |
| WO (1) | WO1999027750A1 (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7010590B1 (en) | 1999-09-15 | 2006-03-07 | Datawire Communications Networks, Inc. | System and method for secure transactions over a network |
| MXPA02002935A (en) * | 1999-09-15 | 2003-09-25 | Datawire Comm Networks Inc | System and method for secure transactions over a network. |
| US7203664B2 (en) | 2003-09-26 | 2007-04-10 | Alliance America Corporation | System and method for annuity valuation |
| US10628263B1 (en) | 2013-08-02 | 2020-04-21 | David Cowen | Logfile-related technologies and techniques |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3120033B2 (en) * | 1996-03-19 | 2000-12-25 | 株式会社東芝 | Distributed memory multiprocessor system and fault recovery method |
-
1997
- 1997-11-20 CA CA 2221661 patent/CA2221661A1/en not_active Abandoned
-
1998
- 1998-11-19 EP EP98955287A patent/EP1031255A1/en not_active Withdrawn
- 1998-11-19 WO PCT/CA1998/001074 patent/WO1999027750A1/en not_active Application Discontinuation
Also Published As
| Publication number | Publication date |
|---|---|
| WO1999027750A1 (en) | 1999-06-03 |
| EP1031255A1 (en) | 2000-08-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7366768B2 (en) | Deploying service modules among service nodes distributed in an intelligent network | |
| US5974429A (en) | Method and apparatus for updating distributed databases in a telecommunications network | |
| USH1964H1 (en) | Resource management sub-system of a telecommunications switching system | |
| MXPA01003970A (en) | Method and apparatus for deploying service modules among service nodes distributed in an intelligent network. | |
| JPH07264287A (en) | Communication system integrating intelligent network and telecommunications management network | |
| US6944657B1 (en) | Automatic network synchronization of the network configuration with the management information database | |
| GB2308778A (en) | Telecommunications network management | |
| CN110737503B (en) | Management method and device for container service snapshot | |
| CA2221661A1 (en) | Transaction roll forward | |
| Rubin et al. | A distributed software architecture for telecommunication networks | |
| CN112565467A (en) | Service processing method, device and storage medium | |
| US6629263B1 (en) | Fault tolerant network element for a common channel signaling (CCS) system | |
| CN115033351A (en) | Distributed transaction compensation method and related device | |
| Cisco | Chapter 4 - Configuring the Cisco MGC Software Releases 9.2(2) and 9.1(5) | |
| Cisco | Chapter 4: Configuring the Cisco Media Gateway Controller Software Release 7.4 | |
| Cisco | Release Notes for the Cisco Media Gateway Controller Software Release 7.4(12) | |
| Cisco | Release Notes for the Cisco Media Gateway Controller Software Release 7.3(17) | |
| KR100194809B1 (en) | Redundant Processor Function Verification Method in Asynchronous Transfer Mode Switching System | |
| AU7109498A (en) | Carrier card interface to a daughter board | |
| JP2000032513A (en) | Structuring method for pbx database | |
| KR100454179B1 (en) | Connection Information Correspondence Method Between TMN Agent And Exchange System | |
| KR100322671B1 (en) | Ain ststem based on international specifications in wire or wireless communication networks | |
| JP2000032514A (en) | Method for structuring dialing project database | |
| Tanaka et al. | Service operation and management architecture using surveillance of application software elements (SOMSE) | |
| KR970007401B1 (en) | Disorder management method of distributed processing system using event number |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| FZDE | Dead |