Update manager for database system

• US 7,734,648 B2
• Filed: 04/11/2006
• Issued: 06/08/2010
• Est. Priority Date: 04/11/2006
• Status: Active Grant

• Current Assignee: SAP SE
• Original Assignee: SAP AG (SAP SE)
• Inventors: Eberlein, Peter
• Primary Examiner(s): Ali; Mohammad
• Assistant Examiner(s): FILIPCZYK, MARCIN R
• Application Number:
  US11/401,423
• Publication Number:
  US 20070239800A1
• Time in Patent Office: 1,519 Days
• Field of Search: 707 1- 3, 707/6, 707 8- 10, 707100-102, 707/200, 707/201, 707/203, 707/205, 709/201, 709/203, 713/168, 713/178, 713/185
• US Class Current: 707/783
• CPC Class Codes: G06F 16/2315 Optimistic concurrency control
• CPC Class Codes: Y10S 707/955 Object-oriented
• CPC Class Codes: Y10S 707/99936 Pattern matching access

Abstract

A database management protocol exchanges update tokens between a client and a server on which the database resides. When a client requests data to be read from a database, an update manager either reads an update token stored therein or generates one dynamically. The update token represents a current state of the data object being read. Sometime thereafter, if the client requests new data to be stored in the object, the client may furnish the update token back to the update manager. The update manager compares the client'"'"'s update token to a local update token representing a current state of the database and, if they match, determines that the state has not changed. If they do not match, an error results.

Claims

1. A data management method, comprising:

in response to a first read request to read data from a group of databases;

reading a requested data object referenced by the first read request from a database of the group of databases, and

returning the requested data object and a first update token to a sender of the first read request, wherein the first update token is generated by applying a hash function to selected data fields of the requested data object for which data inconsistencies cannot be tolerated and the first update token is not changed before any data in the selected data fields of the requested data object is changed, other data fields not selected are omitted by the hash function and the other data fields not selected are data fields for which data inconsistencies can be tolerated; and

in response to a second read request to read the requested data object from the database;

returning the requested data object and the first update token to a sender of the second read request,

in response to a first write request to store updated data for the requested data object to the database;

storing updated data for the requested data object to the database, the updated data comprise updates to at least one selected data fields for which data inconsistencies cannot be tolerated;

generating a second update token by applying the hash function to the selected data fields of the requested data object for which data inconsistencies cannot be tolerated;

in response to a second write request to store updated data for the requested data object to the database;

comparing the second update token to an update token contained in the second write request to store updated data, and

when the second update token and the update token contained in the second write request to store updated data match, storing data received in the second write request to the database,

wherein the second update token and the update token contained in the second write request to store updated data will match even if updates to the requested data object stored at the database have occurred during a time between generation of the update token contained in the second write request to store updated data and the second update token, provided the updates to the stored requested data object are only directed to data fields thereof that are tolerant of data inconsistencies, and

wherein the group of databases comprise a first database that provides native support for update control that prevents inconsistencies introduced by multiple attempts to update same data simultaneously and a second database that does not provide native support for update control that prevents inconsistencies introduced by multiple attempts to update same data simultaneously.

2. The method of claim 1, wherein the first database natively supports update control by a timestamp stored in the first database in association with a respective data object.

3. The method of claim 1, wherein the first database natively supports update control by a count value representing a number of times a respective data object has been updated in the first database, the count value stored in the first database in association with the respective data object.

4. The method of claim 1, further comprising, when a match does not occur, transmitting the requested data object updated by the first write request and the second update token to the sender of the second write request.

5. The method of claim 1, wherein the database keeps a copy of a most recently generated update token.

6. A computer system, comprising

one or more integrated computer servers each comprising a computer processor, the computer servers being interconnected by a computer network and executing, by respective computer processors:

applications to be used by a plurality of distributed operators, the applications including execution engines and associated data sets stored in a group of databases, wherein among the group of databases, a first database provides native support for update control that prevents inconsistencies introduced by multiple attempts to update same data simultaneously, and a second database does not provide any native support for update control, and

an update manager to govern update operations from disparate users to the data sets stored in the group of databases, the update manager adapted to;

in response to a first read request to read data from the group of databases;

read a requested data object referenced by the first read request from a database of the group of databases, and

return the requested data object and a first update token to a sender of the first read request, wherein the first update token is generated by applying a hash function to selected data fields of the requested data object for which data inconsistencies cannot be tolerated and the first update token is not changed before any data in the selected data fields of the requested data object is changed, other data fields not selected are omitted by the hash function and the other data fields not selected are data fields for which data inconsistencies can be tolerated; and

in response to a second read request to read the requested data object from the database;

return the requested data object and the first update token to a sender of the second read request,

in response to a first write request to store updated data for the requested data object to the database;

store updated data for the requested data object to the database, the updated data comprise updates to at least one selected data fields for which data inconsistencies cannot be tolerated;

generate a second update token by applying the hash function to the selected data fields of the requested data object for which data inconsistencies cannot be tolerated;

in response to a second write request to store updated data for the requested data object to the database;

compare the second update token to an update token contained in the second write request to store updated data, and

when the second update token and the update token contained in the second write request to store updated data match, store data received in the second write request to the database,

wherein the second update token and the update token contained in the second write request to store updated data will match even if updates to the requested data object stored at the database have occurred during a time between generation of the update token contained in the second write request to store updated data and the second update token, provided the updates to the stored requested data object are only directed to data fields thereof that are tolerant of data inconsistencies.

7. The computer system of claim 6, further comprising a plurality of client terminals in communication with the one or more integrated computer servers.

8. The computer system of claim 6, wherein the first database natively supports update control by a timestamp stored in the first database in association with a respective data object.

9. The computer system of claim 6, wherein the first database natively supports update control by a count value representing a number of times a respective data object has been updated in the first database, the count value stored in the first database in association with the respective data object.

10. The computer system of claim 6, further comprising, when a match does not occur, transmit the requested data object updated by the first write request and the second update token to the sender of the second write request.

11. The computer system of claim 6, wherein the database keeps a copy of a most recently generated update token.

12. An apparatus for data management, the apparatus comprising:

a memory device having executable instructions stored therein; and

a processor in operable communication with the memory device and operative to;

in response to a first read request to read data from a group of databases;

read a requested data object referenced by the first read request from a database of the group of databases, and

return the requested data object and a first update token to a sender of the first read request, wherein the first update token is generated by applying a hash function to selected data fields of the requested data object for which data inconsistencies cannot be tolerated and the first update token is not changed before any data in the selected data fields of the requested data object is changed, other data fields not selected are omitted by the hash function and the other data fields not selected are data fields for which data inconsistencies can be tolerated; and

in response to a second read request to read the requested data object from the database;

return the requested data object and the first update token to a sender of the second read request,

in response to a first write request to store updated data for the requested data object to the database;

store updated data for the requested data object to the database, the updated data comprise updates to at least one selected data fields for which data inconsistencies cannot be tolerated;

generate a second update token by applying the hash function to the selected data fields of the requested data object for which data inconsistencies cannot be tolerated;

in response to a second write request to store updated data for the requested data object to the database;

compare the second update token to an update token contained in the second write request to store updated data, and

when the second update token and the update token contained in the second write request to store updated data match, store data received in the second write request to the database,

wherein the second update token and the update token contained in the second write request to store updated data will match even if updates to the requested data object stored at the database have occurred during a time between generation of the update token contained in the second write request to store updated data and the second update token, provided the updates to the stored requested data object are only directed to data fields thereof that are tolerant of data inconsistencies, and

wherein the group of databases comprise a first database that provides native support for update control that prevents inconsistencies introduced by multiple attempts to update same data simultaneously and a second database that does not provide native support for update control that prevents inconsistencies introduced by multiple attempts to update same data simultaneously.

13. The apparatus of claim 12, wherein the first database natively supports update control by a timestamp stored in the first database in association with a respective data object.

14. The apparatus of claim 12, wherein the first database natively supports update control by a count value representing a number of times a respective data object has been updated in the first database, the count value stored in the first database in association with the respective data object.

15. The apparatus of claim 12, further comprising, when a match does not occur, transmit the requested data object updated by the first write request and the second update token to the sender of the second write request.

16. The apparatus of claim 12, wherein the database keeps a copy of a most recently generated update token.