Decentralized, Distributed Internet Data Management

• US 20040244004A1
• Filed: 12/29/2003
• Published: 12/02/2004
• 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
• Granted Patent: US 8,005,805 B2
• Time in Patent Office: Days
• US Class Current: 718/100
• 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-5. -5. (Canceled)

6. 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 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 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.

7. The system of claim 6 wherein the root transaction is able to dynamically set concurrency preferences for the resulting distributed transaction, based on client needs.

8. 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;

invocation of the at least one respective service by a thread of the invoking transaction and being parent of any transaction triggered by invocation of a service of another process;

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 triggered by invocation of a service of another process, 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, the method comprising the steps of;

propagating from a first process to a second process a message indicative of a globalCommit operation with respect to a root transaction, said message also indicative of a number or identifying list of invocations which the first process has made to the second process on behalf of the root transaction;

within the second process, comparing the number or list indicated in the message with a count or list within the second process of the number or list of invocations which have been made on behalf of the root transaction;

in the event the comparison yields a non-match, aborting the transaction.

9. The system of claim 8 wherein each process is built using Java.

10. A method for use with 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, invocation of the at least one respective service by a transaction resulting in the creation of a transaction local to the process thereof, the 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 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, the method comprising the steps of:

propagating from a first process to a second process a message indicative of a globalCommit operation with respect to a root transaction, said message also indicative of a number or list of invocations which the first process has made to the second process on behalf of the root transaction;

within the second process, comparing the number or list indicated in the message with a count or list within the second process of the number or list of invocations which have been made on behalf of the root transaction;

in the event the comparison yields a match, proceeding with the globalCommit operation.

11. A method for use with 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, invocation of the at least one respective service by a transaction resulting in the creation of a transaction local to the process thereof, the 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 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, the method comprising the steps of:

propagating from a first process to a second process a message indicative of a globalCommit operation with respect to a root transaction, said message also indicative of a number or list of invocations which the first process has made to the second process on behalf of the root transaction;

within the second process, comparing the number or list indicated in the message with a count or list within the second process of the number or list of invocations which have been made on behalf of the root transaction;

in the event the comparison yields a non-match, aborting the transaction.

12. A distributed 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;

each or any globalCommit message exchange between processes also carrying information about the actual work being committed.

13. The system of claim 12, such information being logged for recoverability in the event of a crash, such information being used for assistance at any time before, during or after global commitment.

14. The system of claim 12 or 13, wherein any globalCommit requires a registration, and wherein the registration for a globalCommit also carries information about the actual work being committed.

15. A method for use in a distributed 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, the method comprising the step of:

for each globalCommit message exchanged between processes, including also information about the actual work being committed.

16. The method of claim 15 further comprising the step of logging such information for recoverability in the event of a crash, such information being used for assistance at any time before, during or after global commitment.

17. The method of claim 15 or 16 further comprising the step of propagating a registration for a globalCommit, wherein the registration for a globalCommit also carries information about the actual work being committed.

18. A distributed 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;

wherein the root invocation or or, alternatively, the root'"'"'s human user is allowed to dynamically set its/his concurrency preferences for the entire invocation.

19. The system of claim 18 wherein the root invocation (transaction) propagates the concurrency preferences with each or any child invocation it makes.

20. The system of claim 19 wherein each invocation propagates the concurrency preferences as it has received them from the root invocation.

21. The system of claim 20 wherein the propagated concurrency preferences at any level in the root invocation'"'"'s invocation hierarchy specify the extent to which shared resource access is desired or allowed or denied among descendant invocations of the root invocation or user and other, concurrent invocations who are also descendants of the same root.

22. The system of claim 20 wherein the propagated concurrency preferences at any level in the root invocation'"'"'s invocation hierarchy specify the extent to which shared resource access is desired or allowed or denied among descendant invocations of the root invocation or user and other, concurrent invocations who are not descendants of the same root.

23. A data management system, referred to as service, comprising:

One or more operations that can be invoked by remote clients;

Some or all such remote clients having one or more associated contexts or transaction contexts;

An invocation by a remote client also containing partial or complete information indicating or containing said client'"'"'s context or contexts;

An invocation, by a remote client, of an operation leading to a new transaction different from, but possibly related to, any existing client transaction;

Such an operation-level transaction being committed before the client context is terminated before globalCommit notification;

The service maintaining an undo operation for such a committed operation;

A failing or failed remote client context leading to the execution of the undo operations of the corresponding committed invocations in the service.

24. The system of claim 23 where some or all undo operations are executed in an order that is the reverse of the order of their original counterparts.

25. The system of claim 23 where in addition the undo operations are chosen or defined in the same system as the one where the corresponding normal operations were executed.

26. The system of claim 23 where some or all undo operations are unknown to a remote client or its context.

27. The system of claim 23 where some or all undo operations are executed after a timeout and independent of whether the client'"'"'s context outcome requires such undo.

28. The system of claim 23 where an undo operation'"'"'s effects are confined to the data managed by the service on which the undo operation is maintained, even if the original operation involved other services.

29. The system of claim 23 where the service keeps locks to ensure that undo operations can be executed correctly.

30. The system of claim 23 where client context-related information is also part of any global commit message exchanges.

31. The system of claim 23 where client context information includes application-specific data.

32. The system of claim 31 where all or part of the context information is logged, i.e. stored on persistent storage, and retrievable by a human. administrator.

33. The system of claim 23 where the service accepts messages indicative of which previously committed operations have to be undone.

34. The system of claim 23 where the service accepts messages indicative of which previously committed operations do not have to be undone.

36. The system of claim 23 where some or all invocations are synchronous.

37. The system of claim 23 where the client can request the undo executions of its invocations at the service while still allowing globalCommit in the end.