| Systems and methods for managing the synchronization of replicated version-managed databases -> Monitor Keywords |
|
|
  Systems and methods for managing the synchronization of replicated version-managed databasesUSPTO Application #: 20060195487Title: Systems and methods for managing the synchronization of replicated version-managed databases Abstract: A system and method for synchronizing a local replicated database with remote replicated databases. Generally, the system includes a local replicated database and a synchronization manager associated with the local replicated database. The synchronization manager may send changes made on the local replicated database to one or more remote replicated databases for reconstruction by the one or more remote replicated databases, and may receive changes made on a remote replicated database. In addition, the synchronization manager may reconstruct changes received from a remote replicated database on the local replicated database. Preferably, the synchronization manager may send, receive, and reconstruct changes independently from one another, i.e., may perform one or more of these activities autonomously and/or asynchronously. (end of abstract)
Agent: VistaIPLaw Group LLP - Irvine, CA, US Inventors: Iain C. Cooke, Gary S. M. Thomson, Lucy Bastin USPTO Applicaton #: 20060195487 - Class: 707200000 (USPTO) Related Patent Categories: Data Processing: Database And File Management Or Data Structures, File Or Database Maintenance The Patent Description & Claims data below is from USPTO Patent Application 20060195487. Brief Patent Description - Full Patent Description - Patent Application Claims
[0001] This application is a continuation of co-pending application Ser. No. 09/991,485, filed Nov. 13, 2001. FIELD OF THE INVENTION [0002] The present invention relates generally to replicated version-managed databases, and more particularly to systems and methods for managing the synchronization of replicated version-managed databases. BACKGROUND OF THE INVENTION [0003] A database transaction is a group of related updates against a database that form a single "unit of work." There are basically two types of transactions: "short transactions" and "long transactions." Short transactions typically take a few seconds or less to complete. A simple example is a bank account transfer, which may involve subtracting the appropriate amount from an entry in one account and adding the same amount to another account. Since this may take a relatively short period of time to complete, the records may be locked while the transaction is in progress to ensure that nobody else is able to change them and create any inconsistencies. [0004] In contrast, a long transaction may take hours, weeks, or months. An example is a transaction within a Geographic Information System (GIS)--a computer-based tool for mapping and analysing spatial data, such as geographic data and engineering designs. During a GIS transaction, an engineer may generate design alternatives or spatial analysts may perform complex "what if" scenarios. Because these transactions may take a long period of time, locking records for an environment with multiple users who need to access the same data is inefficient and counterproductive. Concurrent control becomes a critical issue. [0005] One known method for solving the long transaction problem is version management. A version is a logical copy of the database specific for a small group of users or for a single user without duplication of the data. This allows multiple users simultaneous access to the same data without applying locks to prohibit other users from modifying the same data. A version managed database system maintains these versions and any conflict that arises from them. [0006] A version is a named logical embodiment of a database state distinct from other versions. The number and state of database records visible within a version may change over time. Versions are generally arranged in a tree structure, as depicted in FIG. 1, and any version may be changed by users or processes independently of and without affecting the data visible in another version. It is known in the art to have changes in one version made available to other versions using the processes of reconcile and post. [0007] A state is a labeled snapshot of a version. Each version points to a specific state. Multiple versions may share the same state if desired. If they do, then users may see identical data in both versions. Over time, versions may move from one state to another. As changes are made to a version, its state may change. The states are containers for the changes to the database. As changes are made to a version, the changes are tagged with the appropriate state. Database states are organized as a tree, where the parent/child relationship may be derived from the state lineage. States are not necessarily explicit within all implementations of version-managed databases. [0008] FIG. 1 illustrates these components working together in a version-managed database. V1 is the first version, and S1 is the first state. V1 is set to S1. Then, a change is made to V1. This change is applied to S1, thus creating a new state S2. A new version is created, V2, and is set to S2. Thus, at this time, V1 and V2 are set to S2. Next, V1 changes again, applying the changes to S2 creates a new state, S3. S2, and hence V2, are unchanged by this operation. V3 is created and set to S3. Thus, V3 and V1 are both pointing to S3. [0009] Next, V4 is created, and set to S2. Changes are made to V4, creating a new state derived from S2, called S4. V4 is set to S4. Changes are then made to V3, creating a new state derived from S3 called S5. Changes are next made to V4, creating S6, derived from S4. [0010] Next, V3 is changed, creating S7, derived from S5. A new version, V6, is created, pointing to S7. V6 is changed, creating S8, derived from S7. V6 is changed again, creating S9, derived from S7. V7 is next created, set to S7. Then, V4 is changed, which was pointing to S6 last, creating S10, derived from S6. V7 is then changed, which was last pointing to S7, thus creating a new S11, derived from S7. V7 is changed again, creating S12, then S13. Finally, V6 is changed, creating S14, derived from S9. [0011] This illustration shows the concepts of versions and states and how these two elements interact with each other. [0012] A very common requirement for companies who use these database systems is to be able access the data in multiple, geographically separate locations, as depicted in FIG. 2. Version-managed databases 1a-1d may be connected through a variety of networks 5. This requires a system of replication, where the database is replicated in multiple locations. In such a system, data synchronization management between the databases becomes critical to ensure reliable data at every location. [0013] One such system, "Smallworld 3" from GE Smallworld, Inc., manages the replication and synchronization of version managed databases by relying on a single process to connect live to all of the databases at once in order to synchronize. This single process gains exclusive control of the relevant versions and records in all of the databases being synchronized, thus preventing access to the data during the synchronization process. In the case where the network 5 connecting the version managed databases 1 is unreliable or high-speed communications between database 1 sites is unavailable, single process synchronization may be inefficient. [0014] Accordingly, it is believed that systems and methods for synchronizing replicated version-managed databases would be considered useful. SUMMARY OF INVENTION [0015] The present invention is directed to systems and methods for managing replicated version-managed databases, and more particularly to systems and methods for managing the synchronization of replicated version-managed databases. [0016] In accordance with a first aspect of the present invention, a system is provided for synchronizing a local replicated database with one or more remote replicated databases. Generally, the system includes a local replicated database, and a synchronization manager associated with the local replicated database. In addition, the system may include an interface associated with the local replicated database for communicating with one or more remote replicated databases via a communications link. [0017] The synchronization manager may be configured for sending changes made on the local replicated database to one or more remote replicated databases for reconstruction by the one or more remote replicated databases, and/or receiving changes made on a remote replicated database. In addition, the synchronization manager may be configured for reconstructing changes received from a remote replicated database on the local replicated database. In a preferred embodiment, the synchronization manager may send changes, receive changes, and/or reconstruct changes independently from one another, i.e., may perform one or more of these activities autonomously and/or asynchronously. [0018] In accordance with another aspect of the present invention, a system is provided for synchronizing one or more replicated databases at least intermittently communicating with one another. Generally, the system includes a first replicated database and a second replicated database at least intermittently disconnected from the first replicated database. Generally, at least one of the first and second databases, and preferably both, may include an interface for communicating with each other via a communications link. [0019] The system also includes a synchronization manager associated with each of the first and second databases. For example, the synchronization manager associated with the first database may be configured for sending changes made on the first replicated database to the second replicated database, receiving changes made on the second replicated database, and/or reconstructing changes received from the second replicated database on the first replicated database. Similarly, the synchronization manager associated with the second replicated database may be configured for sending changes made on the second replicated database to the first replicated database, receiving changes made on the first replicated database, and/or reconstructing changes received from the first replicated database on the second replicated database. [0020] Thus, each of the databases in a replicated database network may include a synchronization manager, thereby allowing each database to autonomously and/or asynchronously exchange changes and/or reconstruct changes independent of other databases in the system. Another advantage of the synchronization manager is that it may monitor activities of the local database with which it is associated and selectively perform one or more of its activities when it most efficient to do so. For example, the synchronization manager may send and/or receive changes when the interface of the local database is available, e.g., not being used for other tasks. In addition or alternatively, the synchronization manager may reconstruct changes, e.g., to synchronize the local database with other databases, when the local database has resources, e.g., processor or memory capacity, available or at times that substantially minimize interference with operation of the local database. Thus, the synchronization manager may operate substantially undetected by users of the local database, while still maintaining the local database substantially synchronized with other databases in the network. [0021] Other objects and features of the present invention will become apparent from consideration of the following description taken in conjunction with the accompanying drawings. Continue reading... Full patent description for Systems and methods for managing the synchronization of replicated version-managed databases Brief Patent Description - Full Patent Description - Patent Application Claims Click on the above for other options relating to this Systems and methods for managing the synchronization of replicated version-managed databases patent application. ###  How KEYWORD MONITOR works... a FREE service from FreshPatents1. Sign up (takes 30 seconds). 2. Fill in the keywords to be monitored. 3. Each week you receive an email with patent applications related to your keywords. Start now! - Receive info on patent apps like Systems and methods for managing the synchronization of replicated version-managed databases or other areas of interest. ### Previous Patent Application: System and method for providing a dynamic user interface for workflow in hospitals Next Patent Application: Context based access of files by file system to a client based on detection of related files opened by the client Industry Class: Data processing: database and file management or data structures ### FreshPatents.com Support Thank you for viewing the Systems and methods for managing the synchronization of replicated version-managed databases patent info. IP-related news and info Results in 0.77071 seconds Other interesting Feshpatents.com categories: Tyco , Unilever , Warner-lambert , 3m |
||
