Electrical computers and digital processing systems: support – Multiple computer communication using cryptography – Particular communication authentication technique
Reexamination Certificate
1999-06-02
2004-04-27
Barrón, Gilberto (Department: 2132)
Electrical computers and digital processing systems: support
Multiple computer communication using cryptography
Particular communication authentication technique
C713S181000, C713S193000, C707S793000, C707S793000
Reexamination Certificate
active
06728879
ABSTRACT:
TECHNICAL FIELD
The present invention relates generally to logging in a transaction processing system, and more particularly relates to a transactional log structure.
BACKGROUND OF THE INVENTION
In many information processing applications, a server application running on a host or server computer in a distributed network provides processing services or methods for client applications running on terminal or workstation computers of the network which are operated by a multitude of users. Common examples of such server applications include software for processing class registrations at a university, travel reservations, money transfers and other services at a bank, and sales at a business. In these examples, the processing services provided by the server application typically maintains persistent data or “state” of class schedules, hotel reservations, account balances, order shipments, payments, or inventory for actions initiated by the individual users at their respective stations, such as in a database or other proprietary format data store.
Often, server applications require coordinating processing activities of multiple separate programs (which possibly reside on different computers or in separate processes) that may modify or otherwise affect separately stored persistent data, such as database records on different computers or in separate database tables. For example, a money transfer operation in a banking application may involve updates to account information held in separate databases that reside on separate computers that may be geographically remote. Desirably, groups of these processing activities that form parts of an operation are coordinated so as to take effect as a single indivisible unit of work, commonly referred to as a transaction. In many applications, performing sets of activities as a transaction becomes a business necessity. For example, if only one account is updated in a money transfer operation due to a system failure, the bank in effect creates or destroys money.
A transaction is a collection of actions that conform to a set of properties (referred to as the “ACID” properties) which include atomicity, consistency, isolation, and durability. Atomicity means that all activities in a transaction either take effect together as a unit, or all fail. Consistency means that after a transaction executes, the system is left in a stable or correct state (i.e., if giving effect to the activities in a transaction would not result in a correct stable state, the system is returned to its initial pre-transaction state). Isolation means the transaction is not affected by any other concurrently executing transactions (accesses by transactions to shared resources are serialized, and changes to shared resources are not visible outside the transaction until the transaction completes). Durability means that the effects of a transaction are permanent and survive system failures. For additional background information on transaction processing, see, inter alia, Jim Gray and Andreas Reuter,
Transaction Processing Concepts and Techniques
, Morgan Kaufmann, 1993; and Philip Bernstein and Eric Newcomer,
Principles of Transaction Processing
, Morgan Kaufmann, 1997.
The durability property is important in transaction processing applications because each transaction is usually providing a service that amounts to a contract between its users and the enterprise that is providing the service. For example, if a user is moving money from one account to another, once the user gets a reply from the transaction processing system that the transaction executed, the user really expects that the result is permanent. This expectation may amount to a legal agreement between the user and the enterprise that the money has been moved between the user's accounts. It is therefore essential that the transaction processing system stores the updates to account data on some non-volatile data storage device, typically a hard disk drive, to ensure that the updates from a completed transaction cannot be lost.
Transaction processing systems typically obtain the durability property via a log-based recovery mechanism, which starts with the transaction processing system writing a copy of all the transaction's updates of a durable resource (e.g., a database) into a log file while the transaction is executing. On a request to commit the transaction, the transaction processing system first ensures that all records written to the log file are transferred to the hard disk (not merely in volatile cache memory), before then determining to commit the transaction. The updates to the database can then be written out to disk at any time after the decision to commit. If the system fails after the transaction commits and before the updates are made to the database, the updates can still be made during a recovery process using the persisted log records. During recovery, the system rereads the log and checks that each update by a committed transaction actually was made to the database. If not, the system applies the update to the database. When recovery is complete, the results of all committed transactions will be effected in the database and the transaction system can resume normal operation.
In general, the log is kept as a sequential file on disk, and contains a sequence of records describing updates to a durable resource (e.g., database). These records must contain sufficient information to correctly recover the state of the durable resource including all committed transactions in the event of a failure, such as a before-image, after-image and pointer of the portion of the database affected by the update. This part of a log record is termed the log record's “body,” and typically is provided by a component or subsystem of the transaction processing system referred to as a “resource manager.” During recovery, the information in the log record body is read back (such as, by a recovery manager) to the resource manager. The resource manager uses the after-image to effect updates for transactions that committed before the failure, and uses the before-image to reverse updates for transactions that aborted or were not committed before the failure.
In addition to log records for each update in a transaction, the log also contains log records that report when a transaction commits or aborts. Typically, the body of these log records may just contain the identifier of the transaction and an indication whether the transaction committed or aborted.
In many transaction processing systems, the log is managed by a component or subsystem termed a log manager. The log manager provides an interface by which other subsystems, such as the resource manager, a transaction manager and recovery manager, interact with the log. The log manager also provides a portion of each log record referred to as the log record header, which the log manager uses at recovery to identify the sequence of log records in the log, as well as the resource manager and transaction of each log record. For example, the following declaration defines the structure of an example generic log header.
typedef struct {
LSN
lsn;
/* log sequence number of record */
LSN
prev_lsn;
/* lsn of previous record in log */
TIMESTAMP
timestamp;
/* time log record was created */
RMID
rmid;
/* id of resource manager */
TRID
trid;
/* id of transaction */
LSN
tr_prev_lsn;
/* prev log record of transaction */
long
length;
/* length of log record body */
char
body[];
/* body of log record */
} log_record_header;
The present invention addresses two problems in log design. A first problem is that of maintaining a persistently identifiable log end (i.e., identification of the last complete log record in sequence) while frequently appending log records to the log. After a failure, the only remaining data from which the log end can be identified is the data already stored out to disk prior to the failure. Accordingly, logs for some prior transaction processing systems have stored a pointer to the end of log at a separate location on disk, such as in a separate disk
Barrón Gilberto
Fields Courtney D.
Klarquist & Sparkman, LLP
Microsoft Corporation
LandOfFree
Transactional log with multi-sector log block validation does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Transactional log with multi-sector log block validation, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Transactional log with multi-sector log block validation will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3236238