Reivindicaciones
1. Distributed transactional data Management System according to a client-server model characterized in that - at the server side the transactional data management system is decomposed into different components being: ∘ one commit server component, ∘ one snapshot server component, o at least two transaction managers components, o at least a conflict manager component, o at least a logger component, o at least a data manager component, wherein different components are allocated to different nodes, - at the client side, one or more applications adapted to interact directly or indirectly with the server, each application adapted to i. connect to a transaction manager component, ii. perform more than zero iterations of the following steps: 1. request to a transaction manager component to start a transaction; 2. request to the transaction manager component more than zero read and write operations, 3. request to the transaction manager component to commit or abort the transaction, iii. be notified by the transaction manager component that the transaction has completed either committing or aborting, - wherein each transaction manager component is adapted to start, abort and commit transactions and execute read and write operations upon request from its connected applications, - wherein the commit server component is adapted to send to each transaction manager labels from an ordered sequence, such that, each label is only sent to one transaction manager component, labels are sent by the commit server component either proactively, or reactively upon request from transaction managers components, wherein this ordered sequence of labels represents the sequence of committed transactions, - wherein the snapshot server component is adapted to: 1. receive the used and discarded labels from the transaction managers components, wherein the discarded labels are those labels produced by the commit server component but not used to label any update transaction and the used labels are labels used to label an update transaction whose writes are durable and readable from the data manager component with a snapshot with a label equal or later to its commit label, 2. report snapshot labels to the transactions mangers components either proactively or reactively upon request from the transaction managers components, such that any snapshot label provided by the snapshot server component to the transaction mangers components guarantees that the snapshot server component received all labels equal or lower than this label, - wherein each transaction manager component is also adapted to: 1. assign as start label for starting a transaction one, among those obtained from the snapshot server component, later or equal than the last one used for the previous transaction, 2. assign as committed label to an update transaction willing to commit one of the unused labels received from the commit server component, marking it as used, 3. forward each read operation with the start label to a data manager component, 4. upon completion of a transaction, send a log request with all the changes performed by the transaction to a logger component, 5. upon notification of commit from the logger component, notify the application about the transaction commit, - wherein each logger component is adapted to: 1. be configured with a durability level that determines whether the notification of durability can be given when the log request has been stored either in memory or in persistent storage of the logger component, 2. receive the log request with the set of changes performed by a transaction and store them in memory and in persistent storage, 3. notify the transaction manager component about the durability of the transaction when the durability satisfies the configured durability level, - wherein each conflict manager component is adapted to: 1. be responsible to detect conflicts for a subset of keys, 2. receive the key of updated items labelled with the transaction start label, 3. upon reception of a key of an updated item, store the key, the transaction identifier and its start label and check whether the same key has been updated by any concurrent transaction, a. if the checking is positive, the conflict manager component is adapted to reply the corresponding transaction manager component with an abort notification and also to store this decision, b. if the checking is negative, it is adapted to store the transaction identifier, the key of the updated item and the transaction start label, 4. receive the abort notification of aborted transactions, 5. upon the reception of an abort notification of a transaction, it is adapted to remove the information about the transaction, 6. receive the commit notification of committed transactions with their commit label, 7. upon the reception of a commit notification of a transaction, it is adapted to store its transaction identifier and commit label, - wherein each data manager component is adapted to: 1. store the data items corresponding to a subset of keys, 2. upon receiving a write or read operation from a transaction manager component, to forward write or read operations to the data managers components responsible for the accessed data and to collect the results returning them to the requesting transaction manager component, 3. perform reads given a transaction start label and to provide the latest committed versions of the read data items with a commit label equal or earlier than the start label, 4. perform writes on a private version of the data only visible to read operations from the writing transaction, 5. upon commit of the transaction, label all private versions of the transaction with the transaction commit label and to make them public. 2. The system according to claim 1 wherein: a. each transaction manager component is adapted to send periodically to the commit server component the number of committed update transactions in at least a past period, b. the commit server component is adapted to send periodically to each transaction manager component a subset of labels that is a function of the fraction of committed update transactions sent by the transaction manager component. 3. A system according to claim 1 wherein if the application previously successfully committed any update transaction, the transaction manager component is adapted to wait to start a new transaction from this session till the latest notified snapshot label by the snapshot server component is equal or greater than the last update transaction commit label of the application. 4. A system according to claim 1 wherein at least one of the transaction managers components is adapted to collect the start labels of the oldest active transactions at all transaction managers components obtaining the oldest start label among them and sending the notification to the all conflict managers components and data managers components and wherein, each conflict manager component, is adapted to discard the information about any transaction with an earlier commit label; and, each data manager component is adapted to remove those data versions that are earlier than the oldest version with a commit label equal or lower than the oldest start label of active transactions. 5. A method for processing transactions operating on the distributed transactional data management system according to claim 1, wherein said method comprises the elements of the system interacting with each other in such a way that: transactions are committed asynchronously and in parallel as each commit request is accepted by the transaction manager component at any time and in any order and processed immediately without waiting for any other start or commit operation to complete, assigning as commit label an unused commit label from those obtained from the commit server component, - transactions are started without blocking as each application start request is accepted by the transaction manager component at any time and in any order, assigning as start label for starting a transaction one, among those labels obtained from the snapshot server component, being equal or later than the latest one used, - transactional consistency is guaranteed by making readable only snapshots corresponding to gap-free prefixes of update transactions that are both durable and their writes have completed, as the data manager component o performs reads on the snapshot indicated by the given transaction start label, o provides the latest committed versions of the read data items with a commit label equal or earlier, o and performs item writes on a private version of the data only visible to read operations from the writing transaction.
