EP1766540A1

EP1766540A1 - Automatic synchronisation process for a data file system processed in a plurality of computers

Info

Publication number: EP1766540A1
Application number: EP05757283A
Authority: EP
Inventors: Paul Mccullagh
Original assignee: SNAP Innovation Softwareentwicklungsgesellschaft mbH
Current assignee: SNAP Innovation Softwareentwicklungsgesellschaft mbH
Priority date: 2004-06-22
Filing date: 2005-06-22
Publication date: 2007-03-28
Also published as: WO2005124588A1; EP1610233A1

Abstract

A process is disclosed for the automatic synchronisation of a data file system processed in a plurality of computers temporarily interconnected by a network and in which the data file system is locally stored, the computers being prepared to execute repetition-consistent transactions upon the data file system. In order to enable all computers to work on the latest version of the data file system, every transaction (T1, T2, Ti) executed on the data file system is continuously recorded in a central transaction protocol, an ascending transaction identification code (TNR) and any data sets (D1, D2, Di) affected by the transaction or addresses which give access thereto being stored besides each transaction, and the transaction identification code (TNR) which corresponds to the latest transaction executed by each computer on its local data file system being stored for each computer as a status identification code (ST). Each computer is prepared to generate a local transaction protocol of the transactions executed on its local data file system, when operating without a network connection, and to attach said protocol to the central transaction protocol when it is next connected to the network, and also to read the central transaction protocol starting from the transaction identification code which corresponds to its valid status identification code and to execute said transactions on the local data file system.

Description

Method for the automatic synchronization of a computer-based file system on a plurality of computers

The present invention relates to a method for the automatic synchronization of a computer-aided file system which is processed on a plurality of computers connected via a network, each of which keeps the file system locally stored, each computer being connected to the network temporarily but not permanently, and Every computer is prepared to carry out repetitive transactions on the file system.

In IT systems, a transaction is a sequence of processing steps that can only be carried out together or not at all. Transactional changes to databases can only be saved permanently once the transaction has been completed. They also have to create a consistent state. If for some reason the processing is stopped before the end of the transaction, the data stock must be reset to the state before the start of the transaction. Transactions must therefore meet the following four criteria: atomicity, consistency, isolation and durability (English: ACID).

The present invention relates to transactions that meet yet another condition and are referred to as repetitive transactions. This additional property is that the resulting file system remains the same even if a given transaction Ti, which is executed at a given point in time, has already been carried out once or several times at an earlier point in time.

In many companies, but also in the private sector, groups of computers are connected by local networks or other network connections. Often, a team should be able to work together on a file system. Here, file system is generally understood to be a set of files, databases, programs, text and image files etc. (collectively referred to as transaction data in the following), which e.g. belong to a project that is being edited by a plurality of users who are temporarily connected to each other by a plurality of computers.

There is also the need, for example, to be able to connect to and edit a common file system over the Internet with a laptop. A classic architecture for such a network of computers that are temporarily but not permanently connected via a network is a client-server system, in which the file system of interest is stored in the server computer and changes in the file system of the client -Computers can run. The file system remains stored in the server computer and the client computers change data in the file system of the server computer or access the file system therein as required. However, such a solution means that a user who wants to work on the file system or only want to access it has to be connected to the server computer, which makes the system inflexible, since it may be desirable for individual users with a laptop, for example work with the file system can, even if there is no connection to the server computer.

The latter way of working with the file system without connecting to a server, i.e. Reading and changing data basically only exists if the file system is also stored locally in the individual computer. Then there is the possibility for every user to work with the file system, regardless of whether there is a connection to the server computers or other computers. However, this naturally results in the problem that the individual local file systems must be compared so that all computers belonging to a group of users have a current version of the file system available, which also contains the changes and additions made by other users to theirs Computers have been included. Such an update could e.g. cause every user to download the entire file system in the current version when connecting to the network. With large file systems, however, this is not practical if the amount of data to be transferred is too large.

It is an object of the present invention to provide a method for automatically synchronizing a computer-aided file system which is processed on a plurality of computers which are only temporarily connected via a network.

The characteristic features of patent claim 1 serve to solve this problem. Advantageous embodiments are specified in the subclaims. According to the invention, it is prescribed that a central transaction log, in which each transaction, which is carried out by any of the plurality of computers on the file system, is recorded continuously. In addition to the transaction, an ascending transaction identifier and one or more transaction data or addresses affected by the transaction, which allow access to it, are stored therein. The ascending transaction identifier could be a consecutive numbering, however, any other sequence of identifiers can be used in which a successor can be specified for each identifier and which can be mapped to the natural numbers. Furthermore, a status identifier is stored on each computer, which indicates the transaction identifier in the central transaction log that was assigned to the last transaction carried out there by the respective computer on its local file system. Each computer is prepared to generate a local transaction log of the transactions carried out on its local file system when it is operating without a network connection and to attach this to the central transaction log the next time it connects to the network, the local transaction identifiers being converted into central transaction identifiers. Furthermore, each computer is prepared in such a way that, whenever it reconnects to the network, it reads the central transaction log from the transaction whose transaction identifier corresponds to its status identifier and executes any additional transactions on its local file system.

In an advantageous embodiment, each computer checks the central transaction log for each transaction when it reads. tion whether it was initiated by himself. This check can be carried out by not deleting entries from the local transaction log into the central transaction ID in the local transaction log, but only marking them as transferred in the local transaction log and assigning the corresponding central transaction ID to the entry in the local transaction log. When reading the header data (which includes, in particular, the transaction identifier) of such a central transaction log entry, it can then be checked whether the transaction identifier read from the central transaction log matches that of an entry in the local transaction log. If it is established that the transaction in question was originally carried out by the computer itself, any transaction data associated with the transaction need not be fetched again from the central transaction log, but the transaction in question is simply carried out again on the computer's local transaction data , This basically repeats the transaction in question, which is not necessary in all cases; however, this is done because it is possible that transaction data has been changed in the meantime, ie since the original execution of the transaction, by other transactions. This ensures that all changes on all computers result in the same current version of the file system. On the other hand, in this embodiment, the computer does not fetch the transaction data affected by the transaction in question, thereby reducing the amount of data to be transmitted by the central computer. With the method according to the invention, all users of a group can work with their computers with the current version of the file system, there being no permanent connection to the other computers. This significantly increases the flexibility and effective work opportunities for the users.

In an advantageous embodiment, the transaction log is kept in a central computer which is constantly switched on and is ready for connection by other computers.

The status identifier on each computer corresponds to the number of the transaction that it read and executed from the transaction log when it last connected to the network.

In rare cases, the proposed method can lead to collisions, namely when two computers "simultaneously" carry out transactions on certain data that are incompatible with one another. If, for example, two users are not connected to the network and one in their local file system, for example, completely deletes a data field while the other assigns new data to this data field, a collision occurs in the subsequent processing if the transactions of the first and afterwards the transactions of the second are carried out. In such a case, both computers should be informed of the collision. Furthermore, the possibility to both ^computers' be given to resolve the collision in which the files are manually integrated and merged new current versions.

To ensure that the versions cannot be accidentally overwritten, all versions can be saved on all connected computers. The different versions of the files can either be saved as a complete file or as a so-called delta file, which only contains differences from another version. The different versions of a file are shown in a so-called version tree. Every version, except the first one, has a previous version. In the event that a version emerged as an integration from two previous versions, a reference to a second previous version is saved in addition to a version.

The central computer will usually be a server. In principle, however, it is also possible to implement the central computer function on a computer participating in the group.

The invention is described below in connection with the drawings, in which:

Figure 1 shows a schematic representation of a plurality of computers and the transaction log;

Figures 2, 3 and 4 show flow diagrams illustrating the sequence of steps according to the present method. In FIG. 1, the transaction log is shown schematically as a two-dimensional data field, a transaction identifier ¹ TNR, a respective transaction Ti and one or more transaction data Di being stored therein, which acts on the transaction Ti. In this case, the transaction data itself does not have to be contained in the transaction log, but rather only needs to be clearly identified by address, so that access to the transaction data is possible. Such an address can refer to locally stored transaction data or be a URL address that enables access to data from another computer. Three computers Ci, C ₂ and C ₃ are shown in this example.

The computer Ci has the status identifier ST = 3. He is currently not with the network-related, and the processing performed by the computer C ₃ transaction T ₃ is the last transaction that the computer Ci has conducted on its local file system.

The computer C ₃ is also not in the network and was last connected to the network when the transaction with the transaction identifier TNR = 5 was the last transaction carried out.

The computer C ₂ is connected to the network and has just carried out a transaction Ti with the TNR = i.

Computer C ₃ was used to edit the file system while it was not connected to the network. In this example, the user has carried out the transactions T ₁₀ c ι T _LO c 2 and T _LO c 3 on his computer in the local file system and has saved a local transaction log for these transactions, the format of which with the central transaction log koll matches. When the computer C ₃ now connects to the network, it will transmit its local transactions T _L oc i to T _L oc ₃ and attach them to the central transaction log. The transactions T _LO c ₁ to T _{OC 3} are assigned the transaction identifiers TNR = i + 1, i + 2 and i + 3 in the central transaction log. It is preferred that the computer C ₃ marks the transferred transactions in its local transaction log as transferred and _replaces the local transaction identifiers T _{LOC 1} to T _{L0C 3} with the central transaction identifiers TNR = i + 1, i + 2 and i + 3.

When connected to the network, computer C ₃ also checks whether there are any more transactions in the transaction log after the transaction with the transaction identifier TNR = 5 corresponding to its status identifier ST. If this is the case as in the present example, the computer C ₃ reads the further transactions T to T _{i + 3} and executes them on its local file system and updates its status identifier ST to i + 3.

A peculiarity arises here when the computer C ₃ encounters the transaction Ti _{+ i} , which it initiated itself and has already executed locally on its file system. In principle, it would be possible for the C ₃ to simply execute the transaction again, which would not result in any changes due to the repetitive nature of the transactions. However, it is preferred that the computer checks whether the transaction Ti ₊ i has already been carried out locally by itself. This can be done, for example, by first reading C ₃ from the central transaction log only the transaction identifier TNR = i + 1 and the transaction and checking whether the local transaction ation protocol an entry with the transaction identifier T _{i +} ι is available. If this is the case, the transaction data D affected by the transaction Ti are not fetched again via the central transaction log, but rather C ₃ for the transaction T _{i + 1} simply on its local version D ^loc i ₊₁ , which is what is to be transmitted Data volume reduced since the transaction data does not have to be transferred from the central computer to C ₃ . Repeated execution of transaction T ₊ i on C ₃ will not change the result in many cases, but it makes sense in principle, since transaction data D _{i + 1} affected by transaction Ti ₊ i in the meantime, that is, since the original local execution of transaction T _LO c \ t may have been altered by other computers in such a way that the transaction is wholly or partially canceled. Instead of laboriously checking whether such an interim change has taken place, transaction Ti ₊ i is simply carried out again in each case, which is less complex.

FIG. 2 schematically shows the sequence of steps of the process which enters locally initiated transactions in a local transaction log. In the first step, the user changes the transaction data of the file system. For this purpose, an entry is generated in its local transaction log, the format of which corresponds to that of the central transaction log described above.

FIG. 3 shows the sequence of steps of the process when the computer, after having carried out local transactions, is connected to the network and the central computer. It is then checked whether there is still an entry in the local transaction log is. If so, this is appended to the central transaction log, a new central transaction identifier being assigned and being written to the central transaction log for this transaction being transferred. The transaction attached to the central transaction log can then be marked as transferred in the local transaction log, the central transaction identifier preferably also being transferred to the local transaction log.

FIG. 4 schematically shows the sequence of steps of the process when reading the central transaction log. In the first step, the header data of the entry with the transaction identifier that follows the status identifier of the computer concerned is read from the log. The transaction is then started locally and a determination is made as to whether the current transaction log entry was generated by the same computer. As already described above, this can be done by searching for the transaction identifier read from the central transaction log in the local transaction log. If the transaction ID does not exist locally, the transaction is from another computer. Then, the transaction data Ti and about affected by the transaction T transaction data Di is retrieved from the central computer and executed, the ^{'transaction.} However, if the transaction Ti in question was originally executed by the same computer and written to the central transaction log, the transaction data Di affected by the transaction are fetched from the local transaction log and the transaction Ti is carried out. Then this entry is deleted from the local transaction log.

Claims

claims

Method for the automatic synchronization of a computer-aided file system, in which only repetition-consistent transactions are defined and which is processed on a plurality of computers connected via a network, each of which keeps the entire file system locally, each computer temporarily, but not permanently with the Is connected to the network and the computers are prepared to execute the repeat-consistent transactions on the file system, with each transaction (Ti, T ₂ , ... Ti) being recorded continuously on the file system in a central transaction log, with an ascending next to each transaction Transaction identifier (TNR) and any transaction data (Di, D ₂ , ... Di) affected by the transaction or addresses that allow access to it are stored, and the transaction identifier (TNR) on each computer as status identifier (ST) is saved, the last v corresponds to the transaction carried out on the respective computer on its local file system, each computer being prepared to generate a local transaction log of transactions carried out on its local file system when operating without a network connection and to attach this to the central transaction log the next time it connects to the network and also to read the central transaction log from the transaction identifier that corresponds to the status identifier that applies to it and to execute these transactions on the local file system.

, A method according to claim 1, characterized in that each computer is prepared, when reading the entries in the central transaction log for each transaction to check whether it has been caused by itself and, if so, the transaction on the local repeat affected transaction data.

3. The method according to claim 2, characterized in that when an entry is transferred from the local transaction log to the central transaction log, a central transaction identifier following the transaction identifier of the last entry before the transmission is assigned and assigned to the transmitted entry in the central transaction log, this being the case central transaction identifier for the transmitted transaction log entry is also stored in the local transaction log.

4. The method according to claim 3, characterized in that each computer is prepared to carry out the check when reading an entry from the central transaction log as to whether this has been caused by itself by examining whether the central transaction identifier is also used for an entry in the local transaction log.

5. The method according to any one of the preceding claims, characterized in that the transaction log is kept in a central computer which is constantly switched on and is ready for connection by other computers. Method according to one of claims 1 to 4, characterized in that the transaction log is kept in one of the plurality of computers.