Decentralized, distributed internet data management

• US 6,671,686 B2
• Filed: 11/02/2001
• Issued: 12/30/2003
• Est. Priority Date: 11/02/2000
• Status: Active Grant

• Current Assignee: Gustavo Alonso, Guy Pardon
• Original Assignee: Gustavo Alonso, Guy Pardon
• Inventors: Alonso, Gustavo, Pardon, Guy
• Primary Examiner(s): MOFIZ, APU M
• Application Number:
  US09/682,969
• Publication Number:
  US 20020083078A1
• Time in Patent Office: 788 Days
• Field of Search: 707/8, 707/10, 709/101
• US Class Current: 1/1
• CPC Class Codes: G06F 9/466 Transaction processing
• CPC Class Codes: G06F 9/548 Object oriented; Remote method invocation [RMI] non-remote method invocation G06F9/449
• CPC Class Codes: H04L 43/04 Processing captured monitoring data, e.g. for logfile generation
• CPC Class Codes: Y10S 707/99938 Concurrency, e.g. lock management in shared database

Abstract

A light-weight architecture is provided, where each component is in itself its own advanced mini-transaction processing monitor. To accomplish this, the system is most readily implemented as a set of Java classes. The resulting architecture is as follows. In a composite system, each server is an independent component performing its own scheduling and transaction management. These servers are built using Java and inheriting from the classes provided by the system according to the invention. The interface to each server defines the services it implements. An invocation of one of these services (through remote method invocation) results in the creation of a local transaction (child of the invoking transaction and parent of any transaction that might be triggered by invoking the services of other servers). Each transaction is a thread that (in an exemplary system) can invoke SQL statements in a local database (directly connected to that server) as well as services offered by other servers. All the information that is required to build a global composite transaction is implicitly added by the system to each call. Each transaction is, however, independently handled at each server. That is, the servers neither communicate among themselves nor rely on a centralized component to make scheduling or recovery decisions. In this way, components can be dynamically added or removed from the system without compromising correctness. All a new server needs to know is the interface and address of the servers it will invoke. Regardless of the configuration, the system according to the invention guarantees that transactions executed over these servers will be correct (serializable) and recoverable at a global and local level.

Claims

1. A data management system, said system characterized as a composite system, the system comprising a plurality of processes;

each process having an interface and implementing at least one respective service defined by that interface;

a first invocation of the at least one respective service by a transaction resulting in the creation of a first transaction local to the process thereof, the first local transaction being a child of the invoking transaction and being parent of any transaction triggered by invocation of a service of another process;

a second invocation of the at least one respective service by a transaction resulting in the creation of a second transaction local to the process thereof, the first local transaction being a child of the invoking transaction and being parent of any transaction triggered by invocation of a service of another process;

each transaction comprising the local invocation of at least two resources, each such invocation leading to an internal participant instance for globalCommit;

each such resource and server invocation also containing application-level comments regarding the nature of the invocation, such comments comprising a portion of any globalCommit message exchanges;

each such comment being presented to a human administrator in the event of a global commitment failure;

each process characterized in that if the first transaction and the second transaction conflict but are both children of a same invoking transaction, then the first transaction and the second transaction and ancestors, if any, of the first transaction and the second transaction are not executed concurrently;

each process further characterized in that each transaction local thereto is independently handled at the process;

each process making scheduling and recovery decisions independent of any centralized component.

2. The system of claim 1 wherein each transaction defining a start associated therewith, and a commit associated therewith;

and wherein the condition of not executing concurrently comprises the condition that the start associated with the second transaction must happen after the commit associated with the first transaction.

3. The system of claim 1 each server resource further comprising a lock table;

each invocation of an internal resource including an identifier of the invoking transaction in an entry in the lock table associated with the invocation;

each invocation of an internal resource comprising checking the invocation against any entries in the lock table to determine whether the invocation has an identifier of the invoking transaction matching an identifier of an entry in the lock table, a match defining the condition of the invoking transaction being a child of the same invoking transaction as the invoking transaction of the entry giving rise to a match.

4. The system of claim 1 wherein each resource invocation further comprises an undo operation, the undo operation being local to the resource of the service.

5. The system of claim 4 wherein in the case of aborting transactions that are children of the same invoking transaction, all undo transactions for the same invoking transaction are executed on each resource in the reverse order of their respective executions.