Consistency Requester for Transactional Backup

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Creating a backup of a system with resources involved in transactions often results in inconsistent data due to the snapshot of storage, as it may capture an image with incomplete or inconsistent transaction states.

Innovation Solution

A consistency requester is used to manage transactions, allowing those in a problematic state to exit while preventing new transactions from entering such states until all are resolved, enabling a consistent view of resources to be obtained and used for backup purposes, which can then be released, allowing transactions to re-enter problematic states.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Productivity

If a shadow copy is created of storage involved in transactions, then a backup can be made quickly, but the backup data becomes inconsistent

Engineering Contradiction:
Improvebackup speedVSAvoiddata consistency
Core Design Contradiction:
ProductivityVSReliability

Solution Approach 1:

The system performs preliminary actions by preventing transactions from entering problematic states before the shadow copy is created. The consistency requester blocks transactions that would create inconsistent states, ensuring that when the shadow copy is taken, all transactions are in valid states, thus guaranteeing backup consistency without sacrificing speed.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If transactions are blocked to ensure consistency, then backup consistency is achieved, but system productivity decreases

Engineering Contradiction:
Improvedata consistencyVSAvoidtransaction throughput
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

The system applies partial blocking by only preventing transactions from entering problematic states rather than blocking all transactions. The consistency requester allows transactions to proceed freely as long as they don't create inconsistent states, blocking only the specific problematic cases. This selective approach maintains high transaction throughput while ensuring backup consistency.

Inventive Principle:
Principle #16Partial or excessive action

3Reliability

If transactions in problematic state are allowed to exit, then consistency can be achieved, but time is lost waiting for transactions to complete

Engineering Contradiction:
Improveconsistent view availabilityVSAvoidwait time for consistency
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system implements feedback by continuously monitoring transaction states and dynamically adjusting blocking decisions. The consistency requester receives feedback from the transaction manager about which transactions are in problematic states and adjusts its blocking behavior accordingly. This real-time feedback mechanism allows the system to achieve consistency as quickly as possible by only blocking when necessary, minimizing wait time while ensuring reliable consistent views.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS7991971B2State management for transactional backup consistency
Publication Date: 2011.08.02 MICROSOFT TECHNOLOGY LICENSING LLC
  • US7991971B2 patent drawing
  • US7991971B2 patent drawing
  • US7991971B2 patent drawing

AI summary

Aspects of the subject matter described herein relate to transactions. In aspects, a consistency requester such as a shadow copy service requests to have a consistent view of a set of resources. In response, transactions that are in a problematic state are allowed to exit the problematic state while new and existing transactions that are not in the problematic state are allowed to perform any work except work that takes them into the problematic state. After no transactions are in the problematic state, a consistent view of the set of resources is available. This view may be used by the consistency requester as desired. Afterwards, the consistency requester may indicate that a consistent view is no longer needed. Transactions are then allowed to enter the problematic state. Transactions may also be allowed to enter the problematic state if a timeout elapses.