WO2012168570A1

WO2012168570A1 - Method and system for managing data shared between separate management sites

Info

Publication number: WO2012168570A1
Application number: PCT/FR2012/000217
Authority: WO
Inventors: Thomas PEUGEOT; Denis BOIRON
Original assignee: Cassidian Sas
Priority date: 2011-06-07
Filing date: 2012-05-29
Publication date: 2012-12-13
Also published as: FR2976378A1

Abstract

The invention relates to a data management system (SG) managing at least one datum stored in at least two databases (BD_n, BD_N), which are located in two separate sites (ST_n, ST_N) belonging to a single network, respectively, and which form said data management system. Said datum is associated with a writing access state managed by a master site, and is shared, for reading and writing, by applications installed on the terminals of each site. Said datum can be requested for a writing operation by an application of a local site. The system includes: a means (IG_n, SJ_n, SJ_N) for verifying the writing access state of the datum in the master site; a means (SJ_n, SJ_N) for locking the writing access for the datum in the master site; and a means (IG_n) for processing the operation on the datum in the database of the local site; and a means (SJ_n, SJ_N) for unlocking the writing access for the datum in the master site.

Description

A method and system for managing data shared between separate management sites.

The present invention generally relates to a method and system for managing data shared between at least two separate management sites. More particularly, the invention relates to a method of managing a set of shared data that is accessible by several applications executed in at least two separate management sites forming the data management system.

It is known information systems deployed on several geographically distinct sites, applications executed in said sites sharing the same set of data. By shared data is meant data that is accessible in writing and reading in at least one database by different applications running on the sites of an information system.

Such an information system comprises a database located on a first site considered as the main site. The main site includes a first application for example running in a first user terminal and which connects locally to the database. Applications from other sites remotely connect to the main site database. By remote connection is meant here that each site, geographically distinct, is connected to the other sites by a connection via communication networks. When a terminal user of one of the non-main sites wishes to access, via an application, a shared datum of the database, said terminal connects remotely to the database by the communication network.

Such an information system is considered as integrated when for the same data accessible by several terminals on separate sites, by means of applications, the value of said shared data remains consistent. Indeed, in this case, shared data is only writable by one application at a time in the database. There is no multiple access conflict to the data.

However, during a communication failure between the main site and another site, the user terminal in the other site can not access the shared data of the database. Such a system information is not robust. An information system is considered robust when one of the sites fails or when communication between sites fails, but does not obstruct access to shared data or part of that data to others. information sites. To overcome a problem of robustness, there are multi-site information systems with as many databases as there are sites. The shared data of each database is duplicated in the different other databases. In such a case, this is referred to as replication of data in the various data bases of the system.

There are two types of replication: synchronous replication (eager) and asynchronous replication (lazy).

Synchronous replication between two databases is a database update during a modification of a database.

Data, also referred to as a transaction of data, in one or other of the databases. The integrity of the databases is satisfied at each replication of data in the databases through a two-phase commit ("two phase commit"), including a voting phase and a decision phase. These two phases make it possible to guarantee

20 the coherence of duplicate shared data in the different databases at the end of a transaction on the data.

However, this replication technique results in long transactions on the data because each transaction is added a two-phase commit. Moreover, during a failure of

25 communication between sites, the synchronous duplication of data can not be done since the two-phase validation can not take place. In this case, this implies a problem of robustness of the system.

Asynchronous duplication of data shared between two databases includes execution and validation of a transaction on

30 data located locally in a database. The updates made by duplication are propagated in each database in a deferred manner after the end of the transaction.

For example, if a remote database is unavailable because of a failure, the updates on shared data that are are queued, and then applied when the remote database becomes operational again.

Because of this, the robustness requirement is considered if a site is inaccessible, since the other sites of the information system can operate on their local database.

However, in the case of transactions made almost simultaneously on the same shared data in separate databases, asynchronous replication leads to an inconsistency of the data in each of the databases, since the deferred updates have not been made .

The sharing of data between different sites of a multi-site information system, requires compliance with the requirements of shared data integrity, the robustness of the system in the face of a partial or general failure of the communication between the different sites and the performance of the information system.

The object of the invention is to overcome some or all of the disadvantages of the prior art. For this purpose, the invention proposes a method for managing data shared between several sites of the same information system each comprising a database. Each site locally handles write access to a separate portion of the set of shared data stored in the information system databases.

To achieve this objective, a method makes it possible to manage data stored in at least two databases respectively contained in two distinct sites belonging to the same network, said datum being associated with a write access state managed by a master site, said data being shared in read and write by applications implemented on terminals of each site, and said data being able to be requested for a write operation by an application of a local site. The method comprises the following steps:

a verification of the state of write access to the data in the master site,

if the write access to the data is in the accessible state, a lock of the write access to the data in the master site,

a processing of the operation on the data item in the database of the local site, and - Unlocking the write access to the data in the master site.

The data management system according to the invention manages database integrity conflicts by managing the write access status to each data via a specific master site for each data item. This master site thus makes it possible to avoid simultaneous multiple access to data shared by several applications implemented on terminals of the master site or remote sites. In the invention, access to data means the possibility of reading the data and / or performing a write operation on the data in the databases. Data is associated with an access state. If the data is writable, the associated access state is then in the accessible state. If the write access to the data is locked, the access state is then in the locked state.

Depending on the data to be accessed, the master site may be the local site or may be a site separate from the local site.

According to one embodiment of the invention, the local site is distinct from the master site. The local site communicates with the master site to command the master site to perform the steps of verifying the state of access to the data and locking, unlocking the write access to the data. The method then comprises, before the processing of the operation, a command of a first update of the data in the database of the local site by duplication of the data stored in the database of the master site. The method also comprises, after the processing of the operation, a command for a second updating of the data in the database of the master site by duplication of the data stored in the database of the local site. When the master site is separate from the local site, double local and remote database updates controlled by the local site provide consistent data in both databases before and after processing the operation on the data.

When the master site is separate from the local site and upon detection of a communication failure between the local site and the master site by the local site, the shared data whose write access state is managed by the master site is only readable in the local site database. If the write access to the data has been locked in the master site, the local site stores an access unlock command writing to the data to be transmitted to the master site as soon as the communication between the two sites is again established. If prior to the detection of the failure, the operation on the data was performed in the local site database and the second update was not executed between the two databases, the local site commands a cancellation of the operation on the data in the database of the local site. The data management system executing the method according to the invention is robust. Indeed, during a communication failure between the local site and the remote master site, the local site can read and write access to the local database data to which it manages the write access status, that is to say for these said data the local site is the master site. The local site reads the other data. During the communication failure with the remote site, the local site operates in degraded mode.

According to another embodiment of the invention, the local site is the master site.

According to one or the other embodiments of the invention, a set of data stored by duplication in the two databases is formed of disjoint data groups, one of the groups comprising said data, the state of write access to each data of a group of data being managed by one of the two sites.

According to one or the other embodiments of the invention, the access state to the data is verified in the master site by means of an access table matching an identifier of the data to a token when the write access to the data is in the locked state and deletes the token when the write access to the data is in the accessible state.

The invention also relates to a data management system managing at least one piece of data stored in at least two databases respectively contained in two distinct sites belonging to the same network and forming said data management system, said datum being associated with a data storage system. write access state managed by a master site, said data being shared in read and write by applications implemented on terminals of each site, and said data item being able to be requested for a write operation by an application of a local site. The system includes: means for verifying the state of write access to the data in the master site,

means for locking write access to the data in the master site,

means for processing the operation on the data item in the database of the local site, and

means for unlocking write access to the data in the master site.

The invention also comprises a management site able to manage data stored in at least two separate databases respectively located in two separate sites forming a data management system, the data management site being able to implement the data management system. process according to the invention.

The invention also comprises a computer program adapted to be implemented in a data management site, said program being characterized in that it comprises instructions which, when the program is executed in the data management site. , perform steps of the method according to the invention.

Other features and advantages of the present invention will emerge more clearly on reading the following description of several embodiments of the invention, given by way of non-limiting examples, with reference to the corresponding appended drawings in which:

- Figure 1A schematically shows a shared data management system, according to one embodiment of the invention;

- Figure 1 B schematically shows a management site included in a shared data management system, according to one embodiment of the invention;

FIGS. 2 to 4 are functional diagrams of the data management method, in normal operating mode of the system, according to one embodiment of the invention; and

FIG. 5 is a functional diagram of the data management method, in degraded operating mode of the system, according to one embodiment of the invention.

The different elements appearing in the different figures retain, unless otherwise specified, the same references. In the following, various embodiments will be described according to a representation of a data management system, without, however, restricting the invention to the terms and expressions disclosed. The invention is applicable in any multi-site data management system requiring data sharing between different sites of the system. Different system configurations involving different technologies can be used separately or in combination to implement the embodiments of the invention. As technologies evolve constantly, the embodiments of the invention may require many modifications that are obvious to a person skilled in the art.

Figure 1A is an architecture of a simplified multi-site data management system in which some elements and functional entities are represented, all of which are logical units whose implementation may differ from what is shown. The connections shown in Figure 1 are logical connections, the current physical connections may be different. It is obvious to one skilled in the art that the systems also include other functions and structures. It should be considered that the functions, structures, elements and protocols used in or for communications in the data management system are not relevant to the current invention. Therefore, they do not need to be described in more detail here.

Referring to Figure 1A, an SG data management system is for implementing a shared data management method according to the invention. The data management system comprises N geographically distinct management sites: ST-ι to STN, with the index N being an integer greater than or equal to two. By shared data is meant data that is accessible by the applications of all sites in the management system. Each site ST _n , with 1 <n <N, comprises at least one terminal T _n made available to a user and implementing one or more applications. Each site T _n also includes an access interface

IA _n managing access to a set of data stored in a database BD _n . An application of the terminal T _n can request the access interface access to the database. The AI _n access interface is connected to a server token SJ _n. The token server is able to manage write access states of part of the data of the local database BD _n . In the token server, such data is associated with a write access state that indicates the readability of the data. If the data is writable, the write access state is then in the accessible state. If the write access to the data is locked, then the write access state is in the locked state. The term write access status is also written access state in the following description.

Each ST site _n comprises a communication interface (not shown) for communicating with each other via a communication network R, wired or wireless, such as a WAN ("Wide Area Network" in English) or a LAN (" Local Area Network "in English) using for example the internet protocol IP. The network R can be a secure network. Thus, each ST _n site can communicate with the other sites of the data management system via the network R.

All these units A _n , T _n , IA _n , SJ _n and BD _n are represented in the form of functional blocks, most of which perform functions relating to the invention and can correspond to software and / or hardware modules.

According to an exemplary embodiment of a management site illustrated in FIG. 1B, each site ST _n may more particularly comprise a control unit UC _n connected to a terminal T _n of the site via a communication interface IC _n included in FIG. UC unit _n . The communication interface IC _n also makes it possible to communicate with the communication interfaces of the other sites via the network R. The control unit comprises at least one microprocessor Ml _n , a set of memories ME _n and the database BD _n . The different elements IC _n , Ml _n , ME _n , and

BDn of the control unit are interconnected by a bidirectional bus. The access interface IA _n and the token server SJ _n are considered as software modules and are distributed in the set of memories ME _n . The memories may be volatile or nonvolatile memories, for example EEPROM, ROM, PRM, RAM, DRAM, SRAM, firmware, programmable logic and typically store contents, data or the like. In addition, the memories can store computer program codes, for example the program codes of the operating systems. The memories can be for example random access, or a hard disk, or a combination of these means. Moreover the memories can be removable or detachable memories connected to the control unit. The database may be embedded in the control unit UC _n , or be independent in the form of a database management server (not shown in Fig. 1B) which is connected to the control unit with or without wire. The database may include a processing unit for executing including updates of data and one or more memories for storing the shared data. The communication interface IC _n may comprise one or more reception units for receiving different input data and one or more sending units for sending different output data, the data being control information, requests and responses, for example. The receiving unit and the sending unit comprise a transmitter and / or a receiver or corresponding means for transmitting and receiving information and performing the necessary functions so that the contents, the control information, etc. can be received and or transmitted. The receiving and transmitting units may comprise a set of antennas, the number not being limited to a particular number.

The remainder of the description describes in more detail the different units comprising one of the management sites of the SG system, called the local management site ST _n . The local site ST _n can communicate with at least one remote site STd, with 1 <d <N and d ≠ n, also belonging to the data management system SG, during the execution of the method according to the invention.

The memories of databases BDi to BDN of the data management system SG comprise part or all of the same set of K distinct data, hereinafter described in the description, shared data Dj to D | <, with K an integer greater than or equal to one. In databases, each data is associated with a unique data identifier, such as a unique data storage address in the databases or a unique value related to the data. These shared data Di to D | <are disjointly grouped into groups of data. The same data is stored in only one data group. Each database contains some or all of the different groups of data. In each local database BD _n , among the groups of data stored some groups are considered as groups of master data and are identified as such. in the database, the other groups being considered slave data groups and also being identified as such in the database. Master data groups are distinct from one database to another.

5 A master data group in a local database BD _n is a group of data whose access state associated with each data item of the group is managed locally by the local token server SJ _n - Alternatively a state of Access associated with the master group itself can be stored in the local token server. The data group is considered as a master data group in a database and as a slave data group in the other databases of the multi-site data management system. One of the system databases may include only slave data groups.

For any data belonging to a master data group in the

15 local database and consequently belonging to the corresponding slave data groups in other sites, the local site corresponds to the master site of said data.

A write access to a data of a master data group in the local database BD _n does not require an update of the

In the other databases of the management system. Data from a master data group in the local database is considered to be always up to date.

A slave data group in the local database BD _n is a group of data whose write access status associated with each

The group data is managed in a remote master site separate from the local site.

A remote master site managing the access states associated with the data of a slave data group of the local database may be different from another remote master site managing the access states associated with the data of another group slave data from the database

30 local.

A remote master site STd includes a remote token server SJd for storing the access state associated with each data of the remote master data group corresponding to a slave data group of the local database. A remote master site STd also includes a database, called remote database BDd, storing in part or all of the same data groups as the local database, in particular the data of said remote master data group.

Access to a data of the slave group in the local database BD _n by the local access interface IA _n requires zero, one or two updates of the shared data, depending on the type of access, by duplication data between the slave data group stored in the local database BD _N and the corresponding remote master data group stored in the remote database BDd-

Tn terminal means a workstation such as a laptop, an e-book, a smartphone, a personal computer, a microcomputer, a digital personal assistant or a device embedded in a computer. a vehicle. The terminal Tn comprises one or more local applications A _n able to connect to the local access interface IA _n to request access to shared data.

An application A _n can be an application operating on shared data stored in databases BDi to BDN of the data management system SG. One or more applications Ai to AN form, for example, management software for a multi-site library comprising groups of subscribers, groups of books and groups of authors on several sites.

The applications Ai to A can also correspond to a human resources management software of a large company implanted on several sites. These applications access a set of databases in which groups of employees, groups of managers, business groups, project groups, etc. are registered.

The operations requested by a local application A _n to be performed on shared data imply read or write access to the data in the local database BD _n . More particularly, the write access to the data may correspond to either a data modification operation, a data deletion operation or a data creation operation in a master or slave data group of the data base. local data BD _n . Depending on the required operation and depending on the type of master or slave group including the shared data, access to the data implies different management by the local access interface IA _n .

When reading the data in a master or slave group, the data is considered to be still readable. Before the read operation of the data belonging to a slave data group, an update of the data can be executed between the local database BD _n and the remote database BDd storing the corresponding master data group.

Before a modification of the data in the local database

BD _n for the local application A _n , the write access to the data in all the databases is previously set to the locked access state for the other applications of the system SG. Locking the write access to the data makes it possible to avoid multiple data access conflicts in the various databases of the system.

Before a deletion of the data in the local database BD _n for the application A _n , the write accesses respectively to all the data of the data group including the data to be deleted in all the databases are previously set to locked access status for other SG system applications. Locking write access or group data respectively prevents multiple data access conflicts in different databases.

Before creating data in the local database BD _n for the local application A _n , the write access to a new unique data identifier to be associated with the data to be created in all the databases is previously set the locked access state for other applications of the SG system to avoid any conflict of uniqueness of the data.

In addition, during read or write access to a datum, or its unique identifier, belonging to a zero slave data group, one or two updates of the datum according to the type of operation required, between the local database Bd _n and the remote database BDd including the corresponding master data group are executed. These updates are described in more detail later with reference to the functional diagram shown in FIGS. 2 to 4. The local access interface IA _n analyzes the operation required by the local application A _n and the data or data concerned by the operation. The local access interface IA _n checks via the local token server SJ _n write access state associated with the shared data, the data belonging to either a master data set is a data group of slave the local database BD _n . In order to access verified data in the accessible access state, the access interface IA _n controls the locking and then the unlocking, once the operation is over, access to the data item or the associated data group. for other applications of the SG system. The local token server executes the lock / unlock command of the access interface either locally or by calling a remote token server. If the data belongs to a slave data group, the local access interface IA _n controls one or two updates, depending on the type of access, of the local and remote databases. The updates between the two databases are executed in a known manner. For example, a first database transmits a modified data log to a second database that duplicates the changed data and stores it by overwriting the original data. These updates ensure consistent data across all databases. Similarly, the local access interface IA _n can periodically control the updating of the slave data groups contained in the local database BD _{n in} order to avoid a too great divergence in time between the databases of the system SG. As a variant, it is the processing unit of the local database that controls and executes the update of the slave data groups.

Upon detection of the degraded mode of the SG system, due to failure of the SG system, local access interface IA _n makes it impossible or cancel any operations on data slave groups if such transactions have not been in remote databases that contain the corresponding master data groups. Then, the access interface IA _n controls the unlocking of the access to the data of slave groups that were previously locked. These unlocking operations will be performed as soon as the link is restored.

The local token server checks SJ _n if data from a master data group is accessible. The local token server runs the locking / unlocking access to this data. In the token server SJ _n write access to shared data belonging to a master data group of the local database is locked when the access state associated with the data is stored in the locked state. More particularly, the locked state corresponds to a lock, also called token, associated with the data in the local token server SJ _n . Similarly, in the token server, the write access to the shared data belonging to a master data group of the local database is accessible when the access state associated with the data item is stored in the state accessible, that is, the data is not associated with a token. An access state may also be associated with a local master data group in the local token server, a locked access state being considered the same for all data in the local master data group, with each group data being associated to a token.

According to one embodiment of the invention, the storage of the access state associated with data in a local token server is performed in a local token table TJ _n . The local token table TJ _n matches each unique identifier of shared data belonging to a master data group of the local database BD _n to a token, if the write access to the data is in the locked state. For an identifier of a data included in the token table TJ _n and not matched to a token, the write access to said data is considered to be accessible. Similarly, for an access state associated with a local master data group in the local token server, the server matches all group data to a token, respectively, if the write access to the data group is in the state Locked. A unique data identifier may be matched to a type of token depending on the operation being processed on the shared data. A token, referred to as a modification token, is matched to a data identifier to be modified. In this case, the write access to the data is in the locked state for modification. A token, called the delete token, is matched to a data group identifier in which at least one data item is to be deleted. In this case, the write access to each data item in the group is in the locked state. A token, said creation token, is matched to a data identifier to be associated with the data once it has been created. As a variant, the token table TJ _n only includes the identifiers of the data or group of master data each matched to a type of token as previously described and whose write access to the data is in the locked state. For data identifiers belonging to groups of master data not present in the table, write access to said data is considered to be unlocked and is in the accessible state.

To check whether data of a slave data group is accessible and / or to execute the locking / unlocking of access to this data, the local token server uses the remote token server which manages the state of the data. access associated with said data. The remote token server also includes a token table.

A failure of the SG system is detected by the local token server SJ _n when it can not communicate with a remote server chip. Similarly, a failure of the system SG is detected by the local database BD _n when it can not communicate with a remote database. Alternatively, it is the communication interface of the local site that detects a failure of the SG system when it can not communicate with another communication interface of a remote site. The local site then enters degraded mode and only the data belonging to the master data groups can be read and read by the local applications. Data belonging to slave data groups in the local database and whose write access status can not be verified is only readable.

Depending on the data and / or the operation to be performed on the data of the accessibility rules called RA in the following description may also be associated with the data. These rules must be satisfied to consider the data as accessible. If the accessibility rule associated with the data is satisfied and access to the data is not in the locked state, the data is deemed accessible. On the contrary, if the data is in the accessible state and the associated accessibility rule is not satisfied then the data is deemed not accessible. An example of an accessibility rule RA concerns links established or potentially to be established between data of different groups. These rules make it possible to prevent data related to another data item from the same group or from another data group is deleted, which may result in a database consistency issue. Accessibility rules can also prevent the deletion or modification of certain data when a specific management site or any one is in degraded mode. Accessibility rules can be, for example, applied in a system managing relational databases. These accessibility rules can be stored in a TR rules table that matches each rule to a unique data or data group identifier. The rule table TR can be stored in each access interface of the system SG. To verify the accessibility of shared data, the local access interface must check whether the data is associated with a token and whether the rule associated with the data is satisfied.

In order to communicate with the remote sites, each local site ST _n can include a location table. The location table matches each identifier of groups of data stored in the local database with the identifier of the corresponding master site. This site identifier corresponds for example to a site network address. The location table can be stored in the local access interface IA _n . Alternatively, the location table can be stored also in the local token server. In another variant, the location table TL is stored in any entity of the system SG, for example the communication interface or the local database, making it possible to inform on the identity of a site paired with a group of data. master.

The functional diagrams AG1, AG2 and AG3 represent the steps of the method of managing shared data D belonging to a data group G _m in the local database BD _n , in normal operation of the system SG. Functional diagrams AG1, AG2 and AG3 are implemented in each site of the SG system.

The functional diagram AG1 illustrated in FIG. 2 more particularly comprises the steps of the method according to the invention during a request for read access to a datum of the local database BD _n . The functional diagram AG1 comprises the main steps E1-1 to E1-15.

In step E1 -1, a local application A _n requests access to shared data at the local access interface IA _n . So the application An transmits to the local access interface IA _n a DOP operation request (ld-D) on a data item D identified by the unique identifier Id-D.

At step E1-2, the local access interface IA _n analyzes the request and checks whether the requested DOP operation request requires access to the data read - referenced "READ" in Fig 2 - or writing. If the operation requires write access to the data, the method is executed according to the steps of the functional diagram AG2 described later with reference to FIG. 3. If the operation requires read access to the data, the interface IA access _n checks in step E1 -3, whether the data D belongs to a master data group - referenced GM _n in Figure 2- or a group of data slave. This verification is, for example, performed using the local database in which the membership of the data is defined to a data group slave or master. Alternatively, the verification can be done according to the location table. If the identifier of the data group with the data is matched to the local site identifier then the group is considered a master group. Otherwise, the group is considered a slave group.

In step E1-3, if the data belongs to a slave data group, the access interface checks, in step E1-4, whether the last update of the data between the local database BD _n and the remote database BDd, including the master group corresponding to said slave group, was controlled by the local access interface IA _n . For example, a UD-D indicator, also called "flag" in English, associated with the data D in the access interface IA _n , is set to 1 as soon as the update of the data D, commanded through the local access interface, has been executed. Then, a message notifying the update of the data or the slave data group is sent from the site having ordered the last update to the other remote sites respectively containing the databases storing the data group defined as slave. On receipt of this message, each receiving site sets the corresponding UD-D flag to zero, thereby indicating that the last update of the data D has not been commanded by the access interface of the site. According to this embodiment, the access interface of each site comprises a table matching a UD-D indicator to the unique identifier of a data item D. Others known implementations can be applied to check if the last update of the data D has been controlled by the local access interface.

In step E1 -4, if the last update of the data D has not been commanded by the local access interface (UD-D = 0), then the local access interface controls the updating the data D between the local database BD _n and the remote database BDd. The update is executed in a known manner between the two databases. For example, the access interface IA _n transmits an update request DU (Id-D, Id-STd) to the local database BD _n at step E1 -5. The request D1 comprises the identifier Id-D of the data D and the identifier Id-STd of the remote master site Td comprising the remote database BDd, the identifier Id-STd being able to be stored in the location table. After retransmitting the update request DU (ld-D) from the local database to the remote database, in step E1-6, updating the data D or the associated data group stored in the remote database to the local database, is executed in step E1 -7. According to a known method, updating a datum or a group of data from a first database to a second database is performed by transmitting a data log listing only the differences between the two databases. data base. Data that has not been changed in one of the databases is not updated in the other database. Data that has been changed between the two databases is updated by duplicating the data in one of the two databases to be stored in the other database. After updating the databases, an update response RU (ld-D), in step E1-8, is transmitted from the local database to the local access interface. In step E1 -9, the local access interface takes into account that it is the initiator of the last update of the data item D, for example by setting the indicator UD-D to one, and informs the other remote sites respectively containing the databases storing the data group defined as slave.

In step E1 -10, if the data belongs to a master data group according to step E1-3, or if data D belongs to a data group slave and the local access interface has ordered the last update of the data according to step E1 -4 or step E1-9, then the local access interface informs, the local application that the data D is readable. For example, the access interface IA _n transmits a ROP operation response (OK, Id-D) to the application A _n , identifying the data by its identifier Id-D. Upon receipt of the ROP response (OK, Id-D) and steps E1-1 1 and E1 -12, the application A _n transmits a read operation OP (ld-D) to the local database BD _n via the access interface IA _n , by identifying the data D by its identifier Id-D. On receipt of the operation OP, in the step E1-13, the local database BD _n processes the operation OP on the data D. Then, in the steps E1 -14 and E1-15, the database transmits an acknowledgment of the operation ACK-OP (ld-D) to the application A _n via the access interface IA _n .

In degraded operation mode of the local site T _n , when the local site can not communicate with the remote site T <j, the local access interface may allow or prohibit read access to the data in the database local. This authorization can be established in the accessibility rules RA according to, for example, a desired level of coherence of the data read and / or according to the use that will be made by the local application.

In step E1-2, if the operation required by the local application A _n requires write access to the data, the method is executed according to the steps of the functional diagram AG2. With reference to FIG. 3, the functional diagram AG2 more particularly comprises the steps of the method according to the invention during a write access to the data belonging to a master group of the local database BD _n . The functional diagram AG2 comprises the main steps E2-1 to E2-18.

After verifying that the operation required by the application A _n requires write access to the data, in step E1-2 of the functional diagram AG1, the access interface IA _n checks, in step E2- 1, if the data item D belongs to a master data group GM _n or a group of data slave. Step E2-1 is similar to step E1-3 of the AG1 functional diagram, and is therefore not described in detail. If the data belongs to a slave data group, the method is executed according to the steps of the functional diagram AG3 described later with reference to FIG. 4. If the data belongs to a master data group, the access interface IA _n transmits to the local token server SJ _n , in step E2-2, a DVJ token verification request (ld-D) to verify the write access state to the data. The DVJ request (ld-D) comprises in particular the unique identifier Id-D of the data D. In step E2-3, upon receipt of the DVJ request (ld-D), the local token server SJ _n locally checks in the local token table TJ _n if the identifier of the data Id-D is matched to a token J ,. Then, in step E2-4, the local token server SJ _n transmits a token verification response RVJ (ld-D) to the local access interface IA _n informing write access state to the data D identified in the RVJ response by its identifier Id-D.

In step E2-5, the access interface IA _n receives the response RVJ (ld-D). If the identifier of the data or group of data is matched to a token: TJ _n [ld-D] = J according to the RVJ response, then access to the data is in the locked state. The local access interface IA _n then transmits, in step E2-6, a ROP operation response (NOK, Id-D) to the application A _n indicating that the data D is not accessible in writing. Alternatively, if the write access to the data is in the accessible state and if an access rule RA associated with the data or data group, verified by the local access interface, is not satisfied, the local access interface IA _n transmits, in step E2-6, a ROP (NOK) operation response to the application A _n indicating that the data D is not writable. The application A _n reiterate its operation request again later by running step E1 1 AG1 block diagram.

In step E2-5, if the identifier of the data item or group of data is not matched to a token then the access to the data item is in the accessible state, and, according to the previous variant, if an access rule RA associated with the data or group of data, verified by the access interface is satisfied, the data is considered to be writable. In step E2-7, the local access interface IA _n controls the locking of the write access to the data by storing the state of access to the data in the locked state in the data server. local token SJ _n , in step E2-8. More particularly, the interface IA _n local access token transmits to the local server SJ _n, in step E2-7, a request to create a token DCJ (ld-D) to associate with the data D to lock write access to the data. AT step E2-8, upon receipt of the DCJ request (ld-D) and for a modification operation on the data D, the token server SJ _n matches in the token table TJ _n the identifier of the data Id-D to a modification token. For a data deletion operation D, the local token server SJ _n matches the identifier of the data group G _m associated with the data D to a deletion token, which amounts to matching all the identifiers of the data belonging to the said data group respectively to a delete token. For a data creation operation, the unique identifier Id-D to be associated with the data is generated by the access interface and is matched to a creation token in the local token table TJ _n by the server. of local token SJ _n . Here, the local token server SJ _No message notifies the other token server SG system access to Id-D identifier is locked. On receipt of said message, the other token servers register in their local token table the matching of the identifier Id-D to a creation token.

Then in step E2-9, the local token server SJ _n transmits to the local access interface IA _n a response RCJ (ld-D) of creation of token matched with the identifier Id-D of the data D or the associated data group.

In step E2-10, upon receipt of the RCJ token creation response (ld-D), the local access interface IA _n transmits to the local application A _n a ROP operation response (OK ) indicating that the application A _n can access the data D in the local database BD _n .

According to an alternative embodiment and in order to avoid a large number of message exchanges between the local access interface and the local token server, the verification of the accessibility of the data - step E2-3 - and the creation of a token associated with this accessible verified data item - step E2-8 - are executed in the same step. Steps E2-4 to E2-7 are deleted and a new step is added after step E2-9. In more detail, in step E2-2 modified for this variant, the local access interface transmits a request for token verification and token creation if the data is verified accessible. In steps E2-3 and E2-8, if the data is already locked, no tokens are created. If the data is accessible, a token is created as described above. Then the local token server transmits, in step E2-9, a verification and creation response to the local access interface. Then, in a new stage, the access interface processes the response and transmits a response to the local application. If the access to the data has been verified in the locked state, the access interface transmits to the application the response ROP (NOK, Id-D) - according to step E2-6 - thus indicating that the application can not access the data. By cons, if a token has been created and associated with the data, the access interface transmits the response ROP (OK, Id-D) - according to step E2-10 - indicating that the application can access the data D.

According to one or the other of the preceding embodiments, on receipt of the ROP (OK) response and in steps E2-1 1 and E2-12, the application A _n transmits an operation OP (ld-D) to the local database BD _n via the access interface IA _n , the OP operation to be processed on the data associated with the identifier Id-D. In step E2-13, the local database BD _n receives the operation OP, processes the operation on the data D and returns to the steps E2-14 and E2-15, an acknowledgment of the operation ACK-OP (ld-D), to the application A _n via the local access interface IA _n .

In step E2-16, upon receipt of the acknowledgment ACK-OP, the local access interface IA _n controls the unlocking of the write access to the data by storing the access state to the data in the accessible state in the local token server SJ _n , in step E2-17. More particularly, in step E2-16, the local access interface IA _n transmits to the local token server SJ _n a request to delete DSJ (ld-D) of the token matched with the identifier Id-D of the D data or the associated data group. At E2-17 stage and receiving the token removal request TSD, the local token server SJ _n unlocks access to the data D: TJ _n [ld D] = 0 by removing the associated token to the identifier Id-D.Thus, after a modification operation on the data D, the token server SJ _n deletes in the local token table TJ _n the modification token matched to the identifier of the data Id-D . After a data deletion operation D, the token server SJ _n deletes from the local token table the deletion token paired with the identifier of the data group G _m associated with the data D or alternatively deletes all delete tokens matched respectively to the identifiers of the data belonging to said data group. After a data creation operation, the local token server deletes the creation token matched to the unique identifier associated with the created data and notified by a message the other token servers of the system SG that said identifier Id-D is no longer locked and is associated with data. Upon receipt of the message, the other token servers delete in their local token table the matching of the identifier Id-D to the creation token and also deletes the identifier Id-D. The identifier Id-D associated with the data item created can be stored in each allocation table in association with the group comprising the data item created.

In the step E2-18, the token server SJ _n transmits to the access interface IA _n , a cancellation response RSJ (ld-D) token.

Returning to step E2-1, the data is verified to belong to a slave data group and the method is executed according to the steps of the functional diagram AG3 illustrated in FIG. 4. With reference to FIG. 4, the functional diagram AG3 more particularly comprises the steps of the method according to the invention during a write access to the data belonging to a slave data group of the local database BD _n . The function diagram AG3 comprises steps E3-1 to E3-31.

After checking that the data belongs to a slave data group in step E2-1 functional diagram AG2, the IA _n local access interface transmits in step E2-2 functional diagram AG3, to the server of local token SJ _n a DVJ token verification request (ld-D, Id-STd). The DVJ verification request (ld-D, Id-STd) makes it possible to check the state of access to the data and comprises the identifier of the data Id-D and the identifier of the remote remote site Id-STd associated in the location table to the identifier of the data group having the data D. In step E3-3, the local token server SJ _n having received the DVJ token verification request retransmits the DVJ request (ld-D ) to the remote token server SJd included in the remote master site Td to check the state of access to the data D. The step E3-3 is identical to the step E2-3 of the functional diagram AG2. Then, in step E3-4, to inform the write access state of the data D, the remote token server SJd transmits a token verification response RVJ (ld-D) to the local token server SJ _n which retransmits the token verification response RVJ (ld-D) to the local access interface IA _n in step E3-5.

In step E3-6, similar to step E2-5 of the functional diagram AG2, the local access interface IA _n receives the response RVJ (ld-D) and processes it. Yes the access to the data is in the locked state, that is, if the identifier of the data or data group is matched to a token: TJd [ld-D] = J according to the RVJ response , the local access interface IA _n transmits, step E3-7, application a _n ROP operation response (NOK, Id-D) indicating that the data D identified by the identifier Id-D n is not writable. Alternatively, if the write access to the data is in the accessible state and if an access rule RA associated with the data or data group, verified by the local access interface, is not satisfied, the local access interface IA _n transmits, in step E3-7, the operation response ROP (NOK, Id-D) to the application A _n . The application A _n reiterate its operation request later by rerunning step E1 -1 of AG1 block diagram.

In step E3-6, if the write access to the data item is in the accessible state, that is to say that the identifier of the data item or data group is not matched to a token according to the RCJ response, and according to the previous variant, if an access rule RA associated with the data or group of data, verified by the access interface, is satisfied, the data is considered to be writable. In step E3-8, the local access interface IA _n controls the locking of the write access to the data. More particularly, the local access interface IA _n transmits to the local token server SJ _n , in step E3-8, a request to create a DCJ token (ld-D, Id-STd) associated with the data D in order to lock the write access to the data. The DCJ request includes the identifier of the data Id-D and the identifier of the remote master site Id-STd comprising the remote token server SJd that will execute the request. At the step E3-9, the local token server SJ _n having received the request DCJ forwards the request to create a token to token SJD remote server. The remote token server SJd matches, in step E3-10, in the remote token table TJd, the identifier of the data Id-D to a modification, deletion or creation token according to the required operation. The matching of an identifier of a data to a token in the remote token table, in step E3-10 is identical to that performed in the local token table TJ _n , in step E2-8 of the AG2 functional diagram. In step E3-1 1, the remote token server SJd transmits to the local token server SJ _n a token creation RCJ (ld-D) response matched to the identifier of the data item D or the data group. associated. The local token server SJ _n retransmits the RCJ response to local access interface IA _No, the E3-12 step.

According to an alternative embodiment and in order to avoid a large number of message exchanges between the local access interface and the remote token server via the local token server, the verification of the accessibility of the data - step E3-3 - and the creation of a token associated with this accessible verified data item - step E3-10 - are executed in the same step. Steps E3-4 to E3-9 are deleted and a new step is added after step E3-12. In more detail, in variant modified steps E3-2 and E3-3, the local access interface transmits a token verification and token creation request if the data is verified accessible to the remote token server via the local token server. In the remote token server, in steps E3-3 and E3-10 modified according to the variant, if the data is verified locked, according to the initial step E3-3, no token is created. If the data is verified accessible, according to the initial step E3-3, a token is created as described previously in the initial step E3-10. Then the remote token server transmits via the local token server, in modified steps E3-11 and E3-12, a verification and creation response to the local access interface. Then, in a new step, the local access interface processes the response and transmits a response to the local application A _n . If access to the data has been verified in the locked state according to the probe response and previous creation, local access interface IA _n transmits to the local application A _n ROP response (NOK, Id- D) - according to the initial step E3-7 - thus indicating that the application can not access the data. On the other hand, if a token has been created and associated with the data, according to the previous verification and creation response, the access interface executes step E3-13 as described below. According to this variant, the accessibility rules RA can be processed directly in the remote token server, the data not being writable if the associated rule is not satisfied. Or the accessibility rules can be processed in the local access interface before steps E3-1 and E3-2. Thus steps E3-1 and E3-2 are not executed if the access rule associated with the data is not satisfied.

According to one or the other of the preceding embodiments, in the step E3-13, on receiving the RCJ response, the local access interface IA _n controls a first request for updating DU1 (D, Id-STd) of the data item D or of the data group comprising the data item D between the local database BD _n and the remote master database BDd. The request DU1 is transmitted to the local database BD _n and comprises the identifier of the data Id-D and the identifier of the remote master site Id-STd comprising the remote database. In step E3-14, the local database BD _n transmits the request DU1 to the remote database BDd which, in step E3-15, updates the data or the group of associated data in the database BD local database _n . The update is performed in the same way as in step E1 -7 of the functional diagram AG1. The first update of the local database BD _n , allows the application A _n to operate on an exact and consistent D data. For a data creation operation in the local database, the first update DU1 may not be executed since the data has not yet been created. As a variant for a creation of the data D, the data of the group of data which will comprise the data to be created can be updated a first time, before the creation of the data D.

At the end of the first update, step E3-16, the local database BD _n transmits to the local access management interface lAn a first update response RU1 (ld-D, Id-Sd ) indicating that the update has been performed. At step E3-17, local access interface IA _n takes into account that it is the initiator of the last update of the data D, for example by 1-D SU indicator associated with the data D, and informs other remote sites respectively containing the databases storing the data group defined as slave. Then, the local access interface IA _n transmits to the local application A _n a ROP operation response (OK, Id-D) indicating that the application A _n can access the data D in the database local BD _n . The response ROP includes the identifier Id-D of the data D. On receipt of the response ROP (OK, ld-D) and the steps E3-18 and E3-19, the application A _n transmits an operation

OP (ld-D) on the data D identified by the identifier Id-D, to the local database BD _n via the access interface IA _n . In step E3-20, the local database BD _n receives the operation OP, processes the operation on the data D and returns to the steps E3-21 and E3-22, an acknowledgment ACK-OP (ld-D ) of the operation on the data D to the local application A _n via the access interface local IA _n . At step E3-22, AI _n local access interface transmits a second request for updated DU2 (ld-DD, Id-STD) of the data D or the data group having the data D between the local database BD _n and the remote database BDd. The request DU2 transmitted to the local database BD _n has the identifier Id-D of the data D and the identifier Id-STd of the remote master site with the remote database BDd. the E3-23 step, the local database BD _n updates the data D or the data group having the data D in the remote database DB according to a known method of updating data. This method may be similar to that described during the update of the data D or the data group comprising the data D of the remote database BDd to the local database in step E3-15. The second update is executed for an operation of modification, deletion or creation of the data D which belongs to a group of data slave. After performing the second update, the remote master database BDd may transmit an update response executed RU2 (ld-D) to the local database BD _n which transfers the response to the interface d local access.

After receiving the response RU2, the local access interface IA _n transmits an operation acknowledgment ACK-OP (ld-D) on the data D to the application A _n , at the step E3-26.

Also, after receiving the response RU2, in step E3-27, the local access interface IA _n controls the unlocking of the write access to the data. More particularly, in step E3-27, the local access interface transmits to the local token server SJ _n a request for deletion DSJ (ld-D, Id-STd) of the token paired with the identifier Id-D data D or the associated data group in the remote site token server of the remote site identified by the identifier Id-STd. Upon receipt of the RSJ request, in step E3-28, the local token server transfers the RSJ request to the remote token server SJd- Then in step E3-29, the remote token server deletes the paired token to the identifier Id-D of the data in the remote token table TJd and releases the write access to the data D. In steps E3-30 and E3-31, the remote token server SJd transmits a delete response from the RSJ token (ld-D) to the local token server SJ _n which transfers the RSJ response to the local access interface IA _n . The local site may use multiple simultaneous executions of the AG1 to AG3 functional diagrams when one or more local applications request concurrent access to shared data. Execution of identical steps during the processing of several simultaneous access requests may be shared to optimize the processing time of said requests.

The degraded operation of a local site is established as soon as the local site ST _n can not communicate with a remote site STd. In normal or degraded operation of the local site, local applications can read and write access to shared data belonging to master groups in the local database if the accessibility rules are satisfied. Local applications can also read and write access to shared data belonging to slave groups in the local database when the local site can communicate with the remote master site that manages the write access status to the data of those groups. of slave data, if the accessibility rules are satisfied. In the latter two cases, the local site operates normally according to the functional diagrams AG1 to AG3. Local applications can only read access to the data of the slave data group (s) whose write access states are managed by a site or master sites that can not communicate with the local site. In the latter case and relative to non-writable slave data groups, the local site operates in degraded mode according to the function diagrams AG3 and AG4.

The functional diagram AG4 illustrated in FIG. 5 presents the main steps of the method of managing at least one shared datum D belonging to a group of slave data in the local database BD _n , during the detection of the operation in degraded mode of the SG system, more particularly when detecting a communication failure between the local site and the remote master site managing the data access states of the data group comprising the data D. The AG4 functional diagram is implemented in each SG system site and works in parallel with the function diagrams AG1 to AG3, more particularly to the AG3 function diagram. The AG4 functional diagram mainly comprises the steps E4-1 to E4-1 1. Step E4-1 includes detecting a communication failure between the local site and the remote master site, thereby implying degraded mode operation of the local site. As long as no failure has been detected, step E4-1 is looped back on itself. The communication failure is detected by the local token server or the local database. When the local token server SJ _n can not communicate with the remote token server SJd, in steps E3-2, E3-9 or E3-28 of the function diagram AG3, a communication failure is detected. Or when the local database BD _n can not communicate with the remote database BDd in steps E3-14, E3-15 and E3-23, E3-24 of the function diagram AG3 a communication failure is detected. If a failure is detected in step E4-1, the local token server SJ _n or the local database BD _n transmits to the local access interface IA _n a message Msg-MD (ld-G) notifying the data of the corresponding slave data group identified by the identifier Id-G are not writable. Upon receipt of messages Msg-MD (ld-G), in step E4-2 functional diagram AG4, the local access interface IA _n inform the local application A _n that the required data is available only in reading. To do this, the local access interface transmits a message Msg-read (ld-D) to the application A _n ., The message comprising the identifier Id-D of the data D. Access to the data in Reading mode by the local application is performed according to the function diagram AG1.

Then, in step E4-4, the local access interface IA _n checks whether a token is created in the remote token table TJd and is matched to the identifier Id-D of the data D. For example, if the local access interface IA _n has previously received a token creation response RCJ (ld-D) transmitted in step E3-1 1 AG3 functional diagram, then a token was previously created. The local access interface then transmits to the local token server SJ _n a request to delete the DSJ (ld-D, Id-STd) of the token. The request for deletion DSJ includes the identifier Id-D of the data or group of data matched to the token and the identifier Id-STd of the remote site comprising the remote token server SJd. Then, at step E4-6 , the local token server SJ _n stores the DSJ request (ld-D, Id-STd) in order to transmit it later to the remote SJd token server of the site remote identified by the identifier Id-STd, once the communication between the local site and the remote site will be operational again. The access interface then executes step E4-7. Always step E4-4, if verification indicates that no token is created and is paired with the identifier data Id-D of D, IA _No local access interface directly executes the step E4-9.

At step E4-7, the IA _n local access interface checks whether a transaction related to a write access to the data was performed in the local database BD if _n and a second update of the Operated data has been executed between the local database BD _n and the remote database BDd. For example to verify that a write operation on the data has been executed, the local access interface IA _n verifies that it has received an ACK-OP acknowledgment (ld-D) of the operation, transmitted by the local database in step E3-21 according to the functional diagram AG3. Similarly, for example, to verify that the second update of the data made between the local database BD _n and the remote database is performed, AI _n local access interface verifies that it has received an update response RU2 (ld-D) sent by the local database BD _n , in step E3-25 of the function diagram AG3. If a change has been made in the local database BD _n and no second update between the local database and the remote database has been executed then the local access interface IA _n command to the local database BD _n cancel the previous operation performed on the data D. To do this the access interface transmits a request AOP (ld-D)) cancellation of the operation comprising the identifier Id-D of the data D in step E4-8 of the functional diagram AG4. The local database BD _n restores the data as it was before the processing of the operation. The local access interface then performs step E4-9.

In step E4-9, the local site ST _n checks whether it can communicate again with the remote site STd and can thus detect a return to normal mode operation of the local site. As long as a failure is detected, that is, as long as the local site is in degraded mode, step E4-9 loops back on itself. In step E4-9, when the local site can again communicate with the remote site, the local token server SJ _n or the local database BD _n transmits to the local access interface IA _n a message Msg-MN (ld-G) notifying the return to operation in normal mode and as well as the data of the corresponding slave data group identified by the identifier Id-G are accessible in writing and reading, in step E4- 10. Then in step E4-1 1, the local token server SJ _n transmits the stored token deletion request DSJ (ld-D, Id-ST <) to the remote token server STd which executes the unlocking of the access to the data D by deleting the token matched to the identifier Id-D of the data or data group in the remote token table TJd. Upon returning from the normal operating mode, the local token server may have several stored deletion requests respectively relating to several shared data that may belong to different slave data groups in the local database. The local token server transmits all stored token deletion requests to different remote sites that are inaccessible during degraded mode operation of the local site. Then the local site executes again the step E4-1 of detection of the degraded mode.

The execution of the shared data management method in degraded mode is not limited to the succession of steps according to the functional diagram AG4. Several steps can be executed simultaneously. For example, step E4-2 and the set of successive steps E4-4 to E4-8 can be executed in parallel.

The data consistency requirement in the various databases of the SG system according to the invention is satisfied. On the one hand, by managing a write access state to each data by a single specific master site for each data that avoids multiple simultaneous access to the data by different applications of the system SG. Indeed, only one application at a time of the system SG can write access to the data in all the databases of the system and the write access to the data is locked for the other applications of the system. On the other hand, each operation is processed on a consistent data. Indeed, either the data belongs to a master group of the local database and is considered always up to date, or the data belongs to a slave group of the local database and the two updates controlled by the local site allow to have a consistent data in both databases before and after processing the operation on the data. In degraded operation of the local site, if access to data belonging to a master data group has been locked by another remote site prior to the communication failure between the two sites, the write access to the data remains locked for the local site until a command to unlock access to the data has been transmitted by the other site in step E4-11 of the AG4 functional diagram applied in the remote site.

The requirement of robustness of the SG system according to the invention is satisfied since in degraded mode of the local site only part of the data shared in the local database is inaccessible in writing. The local site continues to read and write access to the shared data belonging to the master data groups in the local database and also belonging to the slave data groups whose data access states are managed by accessible remote master sites. by the local site. A local site with a database that includes only slave groups can still read from the local database.

An end user sees the SG system as ergonomic and efficient. Indeed, all ancillary operations of the system such as the first and second data updates in the SG system databases are transparent to the user. In addition, access to local master data group data is as efficient as accessing data from a non-distributed database. Indeed, access to these data does not require systematic updating between two databases and exchange with a remote token server.

In one example, a multi-site data management system SG manages relational databases. Each relational database on the same site stores data in the same group according to the same characteristic. For example, in a data management system such as the management of a multi-site library, one or more groups may include data relating to book titles each data may be associated with additional information on the book. One or more groups may include data related to library subscribers each data may be associated with information characterizing the subscriber such as personal information. And one or more groups may include author-related data each data that may be associated with information characterizing the author, such as its bibliography. A data item of a group may be linked to at least one data item from another group. For example, data relating to a subscriber in a subscriber group is related to data relating to a book borrowed by the subscriber in a book group which itself is related to data relating to the author of the book in a group of authors. The links between two data can be stored in link tables, a link between two data corresponding to the pairing of the two identifiers of the two data. In the databases, each data group may comprise a link table matching the identifier of a group data to one or more data identifiers of other groups. According to this relational database example, a write operation on a datum may correspond to the establishment or the deletion of a link between two data of different groups. A write operation may also include editing, deleting, or creating data in a data group. To perform a write operation on a first datum linked to a second datum, the two data must first be checked accessible and locked. The accessibility check of each of the two data and the locking of each of the two data are carried out according to the steps E2-2 to E2-9 of the functional diagram AG2 and / or the steps E3-1 to E3-12 of the functional diagram AG3. , that either of the two data belong to a master or slave data group in the local database. Then the write operation on the first data item is executed according to steps E2-10 to E2-15 of the function diagram AG2 if the data item belongs to a master data group, or according to steps E3-13 to E3-26. of the AG3 function diagram if the data belongs to a slave data group. Then the two linked data are unlocked according to the steps E2-16 to E2-18 of the function diagram AG2 and / or E3-27 to E3-30 of the function diagram AG3, depending on whether one or the other of the two data belongs to a master or slave data group. According to this example, the specific RA accessibility rules associated with the groups or each shared data of a group can take into account the different links established between the data of the different groups. For example, an accessibility rule relating to the deletion of data may be associated with the data preventing any deletion of the data when the data is linked to one or more other data of another group.

The invention described herein relates to a shared data management method implemented in each site of an SG data management system. According to one implementation, the steps of the method of the invention are determined by the instructions of a computer program incorporated in the control unit of each site of the system SG. The computer program capable of being implemented in part in each unit of each site of the SG system of the invention comprises program instructions which, when said program is executed in each site of the SG system whose operation is then controlled. by executing the program, perform a management of data shared between several sites of the SG system according to the method of the invention.

Accordingly, the invention also applies to a computer program, in particular a computer program recorded on or in a computer readable recording medium and any data processing device, adapted to implement the computer program. 'invention. This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code such as in a partially compiled form, or in any other form desirable to implement the method according to the invention. The program can be downloaded to the device via a communication network, such as the internet.

The recording medium may be any entity or device capable of storing the program. For example, the medium may comprise storage means on which the computer program according to the invention is recorded, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a USB key, or magnetic recording means, for example a hard disk.

Claims

1 - Method for managing a datum (D) stored in at least two databases (BD _n> BDd) included respectively in two distinct sites (ST _n , STd) belonging to the same network, said datum being associated with a datum write access state managed by a master site, said data being shared in read and write by applications implemented on terminals of each site, and said data item being able to be requested for a write operation by an application of a local site, said method comprising the following steps:

- checking (E2-3, E3-3) of the write access state to the data in the master site,

- if the write access to the data is in the accessible state, locking (E2-8, E3-10) of the write access to the data in the master site,

processing (E2-13, E3-20) of the data operation in the local site database, and

- Unlocking (E2-17, E3-29) write access to the data in the master site.

2 - Method according to claim 1, characterized in that the local site is distinct from the master site, the local site communicates with the master site to control the master site the execution of verification steps (E3-3) of the state of access to the data and locking (E3-10), unlocking (E3-29) of the write access to the data.

3 - Process according to claim 1 or 2, characterized in that it comprises before the processing of the operation, a command of a first update (E3-13 to E3-16) of the data in the database data from the local site by duplicating the data stored in the database of the master site.

4 - Process according to any one of claims 1 to 3, characterized in that it comprises after the processing of the operation, a control of a second update (E3-22 to E3-25) of the given in the database of the master site by duplication of the data stored in the database of the local site.

5 - Process according to any one of claims 1 to 4, comprising a detection (E4-1) of a communication failure between the local site and the master site by the local site, the shared data whose write access status is managed by the master site is read only in the database of the local site.

6 - Process according to any one of claims 1 to 5, characterized in that during a communication failure between the local site and the master site, if the write access to the data has been locked in the site master, the local site stores (E4-6) a command to unlock the write access to the data to be transmitted to the master site as soon as the communication between the two sites is established again.

7 - Process according to any one of claims 1 to 6, characterized in that during a communication failure between the local site and the master site, if prior to the detection of the failure operation on the data has was performed in the local site database and that the second update was not executed between the two databases, the local site commands (E4-8) a cancellation of the operation on the data in the database. local site database.

8 - Process according to claim 1, characterized in that the local site is the master site.

9 - Method according to any one of claims 1 to 8 characterized in that a set of data stored by duplication in the two databases is formed of disjoint data groups, one of the groups comprising said data, l write access status of each data of a data group being managed by one of the two sites. 10 - Process according to any one of claims 1 to 9, characterized in that the state of access to the data is verified in the master site by means of an access table (TA _n ) matching an identifier from the data (Id-D) to a token (J) when the write access to the data is in the locked state and deletes the token when the write access to the data is in the accessible state.

1 1 - Data management system (SG) managing at least one datum (D) stored in at least two databases (BD _n , BDd) included respectively in two distinct sites (ST _n , STd) belonging to the same network and forming said data management system, said data being associated with a write access state managed by a master site, said data being shared in read and write by implemented applications on terminals of each site, and said datum being able to be requested for a write operation by an application of a local site, said system comprising:

means (IG _n , SJ _n , SJd) for verifying the state of write access to the data item in the master site,

means (SJ _n , SJd) for locking write access to the data in the master site,

means (IG _n ) for processing the operation on the data item in the database of the local site, and

means (SJ _n , SJd) for unlocking write access to the data in the master site.

12 - Data management system according to claim 1 1, being able to implement a method according to one of claims 1 to 10.

13 - Management site (ST _n , STd) being able to manage data (D) stored in at least two separate databases (BD _n , BDd) included respectively in two separate sites (ST _n , STd) forming a system data management system, the data management site being able to implement the method according to one of claims 1 to 10.

14 - Computer program capable of being implemented in a data management site (ST _n ), said program being characterized in that it comprises instructions which, when the program is executed in the data management site , perform steps of the method according to one of claims 1 to 10.