ES2584102T3 - Sistema y método para procesamiento transaccional de baja contención y descentralizado altamente escalable - Google Patents
Sistema y método para procesamiento transaccional de baja contención y descentralizado altamente escalable Download PDFInfo
- Publication number
- ES2584102T3 ES2584102T3 ES12788505.1T ES12788505T ES2584102T3 ES 2584102 T3 ES2584102 T3 ES 2584102T3 ES 12788505 T ES12788505 T ES 12788505T ES 2584102 T3 ES2584102 T3 ES 2584102T3
- Authority
- ES
- Spain
- Prior art keywords
- transaction
- commit
- component
- tag
- manager
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2379—Updates performed during online database operations; commit processing
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2315—Optimistic concurrency control
- G06F16/2322—Optimistic concurrency control using timestamps
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1474—Saving, restoring, recovering or retrying in transactions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/82—Solving problems relating to consistency
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Databases & Information Systems (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Sistema de gestión de datos transaccional distribuido según un modelo cliente-servidor caracterizado porque - en el lado del servidor el sistema de gestión de datos transaccional se descompone en diferentes componentes que son: o un componente de servidor de commit, o un componente de servidor de snapshot, o al menos dos componentes de gestores de transacciones, o al menos un componente de gestor de conflictos, o al menos un componente logger, o al menos un componente de gestor de datos, en el que diferentes componentes están asignados a diferentes nodos, - en el lado del cliente, una o más aplicaciones adaptadas para interaccionar directa o indirectamente con el servidor, estando adaptada cada aplicación para i. conectarse a un componente de gestor de transacciones, ii. realizar más de cero interacciones de las etapas siguientes: 1. pedir a un componente de gestor de transacciones que comience una transacción; 2. pedir al componente de gestor de transacciones más de cero operaciones de lectura y escritura, 3. pedir al componente de gestor de transacciones que comprometa o aborte la transacción, iii. recibir una notificación por el componente de gestor de transacciones de que la transacción se ha completado o bien comprometiendo o bien abortando, - en el que cada componente de gestor de transacciones está adaptado para comenzar, abortar y comprometer transacciones y ejecutar operaciones de lectura y escritura tras la petición de sus aplicaciones conectadas, - en el que el componente de servidor de commit está adaptado para enviar a cada gestor de transacciones etiquetas desde una secuencia ordenada, de manera que, cada etiqueta sólo se envía a un componente de gestor de transacciones, las etiquetas se envían por el componente de servidor de commit o bien de manera proactiva o bien de manera reactiva tras la petición de componentes de gestores de transacciones, en el que esta secuencia ordenada de etiquetas representa la secuencia de transacciones comprometidas, - en el que el componente de servidor de snapshot está adaptado para: 1. recibir las etiquetas usadas y descartadas procedentes de los componentes de gestores de transacciones, en el que las etiquetas descartadas son aquellas etiquetas producidas por el componente de servidor de commit pero no usadas para etiquetar ninguna transacción de actualización y las etiquetas usadas son etiquetas usadas para etiquetar una transacción de actualización cuyas escrituras son duraderas y legibles desde el componente de gestor de datos con una snapshot con una etiqueta igual que o posterior a su etiqueta de commit, 2. notificar etiquetas de snapshot a los componentes de gestores de transacciones o bien de manera proactiva o bien de manera reactiva tras la petición de los componentes de gestores de transacciones, de manera que cualquier etiqueta de snapshot proporcionada por el componente de servidor de snapshot a los componentes de gestores de transacciones garantiza que el componente de servidor de snapshot recibió todas las etiquetas iguales o inferiores a esta etiqueta, - en el que cada componente de gestor de transacciones también está adaptado para: 1. asignar como etiqueta de comienzo para comenzar una transacción una, entre las obtenidas desde el componente de servidor de snapshot, posterior a o igual que la última usada para la transacción anterior, 2. asignar como etiqueta comprometida a una transacción de actualización dispuesta a comprometer una de las etiquetas no usadas recibidas desde el componente de servidor de commit, marcándola como usada, 3. transferir cada operación de lectura con la etiqueta de comienzo a un componente de gestor de datos, 4. tras completarse una transacción, enviar una petición de registro con todos los cambios realizados por 5 la transacción a un componente logger, 5. tras la notificación de commit desde el componente logger, notificar la aplicación sobre el commit de transacción,
Description
5
10
15
20
25
30
35
40
45
50
DESCRIPCION
Sistema y metodo para procesamiento transaccional de baja contencion y descentralizado altamente escalable Campo de la invencion
La presente invencion se refiere al campo de la gestion de datos transaccional y mas particularmente, gestion de datos transaccional distribuida.
Antecedentes de la invencion
Las organizaciones conffan cada vez mas en sistemas basados en ordenador para almacenar y acceder a la informacion. La informacion se almacena en almacenes de datos. Una cuestion clave para almacenar y acceder a la informacion en almacenes de datos en la consistencia garantizada por el almacen de datos. Una de las maneras mas comunes para proporcionar consistencia es por medio de gestion de datos transaccional normalmente proporcionada por bases de datos y sistemas de multiples niveles, y mas recientemente mediante otros almacenes de datos modernos.
Una transaccion es un proceso que permite el acceso concurrente a datos compartidos y la garantia de manera implfcita (sin ninguna coordinacion directa entre aplicaciones de clientes) de las denominadas propiedades ACID, atomicidad, consistencia, aislamiento y durabilidad. La atomicidad garantiza que el efecto de una transaccion es todo o nada, es decir, que o bien tienen efecto todas sus escrituras o bien ninguna de ellas, incluso en el caso de fallos. La consistencia es una propiedad garantizada por la correccion de las aplicaciones de cliente, si una transaccion se ejecuta sobre una base de datos en un estado consistente con respecto a la semantica de la aplicacion el resultado tras ejecutar y comprometer (“committing”) la transaccion debe ser de nuevo consistente, es decir, las aplicaciones de cliente deben ser correctas. El aislamiento es una propiedad que regula como se gestionan transacciones concurrentes para que observen y escriban datos con un conjunto de garantfas dado. La durabilidad es una propiedad que establece que una vez que se ha comprometido satisfactoriamente una transaccion sus escrituras no pueden perderse incluso en el caso de fallos.
El aislamiento de transacciones se garantiza por medio de control de concurrencia. Un mecanismo de control de concurrencia comun se denomina aislamiento de snapshot. El aislamiento de snapshot divide la atomicidad en dos puntos: lecturas que se producen de manera logica al comienzo de la transaccion y escrituras que se producen de manera logica al final de la transaccion. Se trata de un nivel de aislamiento ligeramente mas relajado que la serializabilidad en la que la atomicidad de una transaccion se produce en un unico punto, es decir, la lectura y las escrituras de la transaccion se producen en un unico punto logico. El aislamiento de snapshot solo rechaza escrituras concurrentes, mientras que la serializabilidad rechaza adicionalmente lecturas y escrituras concurrentes en los mismos elementos de datos.
Un problema clave en la gestion de datos transaccional es como escalar el procesamiento. Es decir, como usar un numero creciente de recursos computacionales para procesar una tasa superior de transacciones.
Una transaccion, tras el comienzo, se asigna a una snapshot de la base de datos, es decir, el conjunto de escrituras comprometidas que observara. El aislamiento de snapshot es un metodo de aislamiento de multiples versiones. Para cada elemento de datos se mantienen multiples versiones que se identifican con etiquetas de orden. Estas etiquetas tambien se denominan marcas de tiempo en el estado de la tecnica. Cuando se compromete una transaccion de solo lectura (transacciones que no han realizado ninguna escritura), no se emprende ninguna accion especial. Cuando se compromete una transaccion de actualizacion (una transaccion que ha realizado al menos una escritura), se asigna un orden en la secuencia de transacciones comprometidas. Es decir, para dos transacciones de actualizacion comprometidas cualesquiera el orden en la secuencia determina que una se comprometio antes de la otra. El aislamiento de snapshot se garantiza en la actualidad comprometiendo transacciones de actualizacion secuencialmente y dando a las nuevas transacciones comenzadas una snapshot correspondiente a la secuencia actual de transacciones de actualizacion comprometidas.
Adicionalmente, no se permite que transacciones concurrentes actualicen elementos de datos comunes. Los conflictos o bien se resuelven cuando se producen abortando una de las transacciones en conflicto o bien en el momento del commit abortando una transaccion de commit que es concurrente con una transaccion de conflicto que se ha comprometido antes que ella.
El tipo de procesamiento transaccional crea contencion debido a varios motivos. El motivo principal es que el procesamiento de commit y la sincronizacion entre el comienzo de nuevas transacciones y el commit de completitud se convierten en un cuello de botella.
En la presente invencion, se elimina este cuello de botella y su cuello de botella final todavfa permite ejecutar tasas muy altas de transacciones de actualizacion conservando completa la consistencia transaccional.
Descripcion de la invencion
5
10
15
20
25
30
35
40
45
50
La invencion resuelve los problemas mencionados en el estado de la tecnica implementando un sistema de gestion transaccional caracterizado porque la gestion transaccional se descompone en diferentes componentes que pueden asignarse a diferentes nodos en el que
- En el lado del servidor, el sistema de gestion transaccional comprende
o Un servidor de commit: es un componente que proporciona etiquetas, denominadas etiquetas de commit, desde una secuencia ordenada. Esta secuencia ordenada de etiquetas representa la secuencia de transacciones comprometidas. Se dice que una etiqueta de commit A que aparece antes que otra etiqueta de commit B en la secuencia es inferior a B o anterior a B y se dice que la etiqueta B es superior a A o posterior a A.
o Un servidor de snapshot: es un componente que proporciona la ultima snapshot (conjunto de actualizaciones comprometidas) en la que pueden comenzarse las transacciones con garantias de aislamiento. Esta snapshot se representa por la etiqueta de commit de la ultima transaccion de actualizacion incluida en la snapshot y tambien se denomina etiqueta de snapshot,
o Al menos un gestor de transacciones: un gestor de transacciones gestiona el ciclo de vida de un subconjunto de las transacciones. Cada transaccion se gestiona por un gestor de transacciones,
o Al menos un gestor de conflictos: un gestor de conflictos es un componente que detecta y maneja transacciones en conflicto. Cada gestor de conflictos controla el manejo del conflicto de un conjunto de claves. Por tanto, cada clave se maneja por un solo gestor de conflictos,
o Al menos un logger: un logger es un componente que esta a cargo de garantizar la durabilidad de actualizaciones de un subconjunto de transacciones comprometidas,
o Al menos un gestor de datos: un gestor de datos es un componente que gestiona operaciones sobre datos. Un gestor de datos gestiona un subconjunto de claves, es decir, es responsable de operaciones sobre datos cuyas claves pertenecen al subconjunto del que es responsable. Un gestor de datos puede almacenar los datos o bien localmente o bien remotamente. Cada clave esta asociada a un solo gestor de datos.
- En el lado del cliente, una o mas aplicaciones adaptadas para interaccionar directa o indirectamente con el servidor, estando adaptada cada aplicacion para:
i. Conectarse a un gestor de transacciones.
Cada aplicacion interacciona con el sistema de gestion de datos transaccional a traves de un gestor de transacciones. La aplicacion de cliente se conecta en primer lugar a uno de los gestores de transaccion (por ejemplo, tomando su direccion de un registro bien conocido donde se almacenan las direcciones de todos los gestores de transaccion disponibles) y se asocia con el. La aplicacion puede realizar varias transacciones con el gestor de transacciones conectado. Cada transaccion se realiza invocando primero a la operacion de comienzo, invocando despues a una o mas operaciones de lectura y escritura e invocando finalmente o bien a commit o bien a aborto.
ii. Realizar cero o mas iteraciones de las etapas siguientes:
1. Pedir a un gestor de transacciones que comience una transaccion.
Cuando una aplicacion se conecta a un gestor de transacciones, el gestor de transacciones asocia a la aplicacion un identificador de conexion unico que se almacena localmente y se devuelve como resultado de la operacion de conexion. Tras la invocacion de la operacion de comienzo por una aplicacion, un gestor de transacciones la asocia a un identificador de transacciones unico, asocia la transaccion a un gestor de datos y selecciona una etiqueta de comienzo inferior que o igual a la ultima etiqueta de snapshot recibida desde el servidor de snapshot (normalmente la ultima recibida desde el servidor de snapshot) y almacena en una tabla de transacciones local el identificador de transacciones, el identificador de conexion, la etiqueta de comienzo y el identificador del gestor de datos.
2. Pedir al gestor de transacciones cero o mas operaciones de lectura y escritura.
Un gestor de transacciones tras recibir una invocacion de operacion de lectura desde una aplicacion transfiere la operacion al gestor de datos asociado a la transaccion. El gestor de transacciones tras recibir el resultado de la operacion de lectura transfiere los resultados a la aplicacion.
Un gestor de transacciones tras recibir una invocacion de operacion de escritura desde una aplicacion de cliente, transfiere la operacion al gestor de datos asociado a la transaccion.
5
10
15
20
25
30
35
40
45
50
Tras recibir el resultado de la operacion de escritura, si fue satisfactoria, almacena las actualizaciones devueltas asociadas al identificador de transacciones y devuelve el resultado a la aplicacion. Si la operacion no fue satisfactoria debido a un conflicto detectado por un gestor de conflictos, el gestor de transacciones aborta la transaccion, eliminando toda la informacion local asociada a la transaccion y almacena el identificador de transacciones con el estado de aborto en la tabla de transacciones.
3. Pedir al gestor de transacciones que comprometa o aborte la transaccion.
Un gestor de transacciones tras recibir una invocacion de operacion de aborto desde una aplicacion de cliente la transfiere al gestor de datos asociado. La operacion de transaccion de aborto indica el identificador de transacciones. Despues, elimina toda la informacion asociada a la transaccion y almacena el identificador de transacciones con el estado de aborto en la tabla de transacciones. El gestor de datos, tras recibir una operacion de aborto la transfiere a todos los gestores de datos implicados en la transaccion. Cada gestor de datos descarta todas las versiones privadas asociadas al identificador de transacciones.
iii. Recibir una notificacion por el gestor de transacciones de que la transaccion se ha completado o bien comprometiendo o bien abortando.
- En el que cada gestor de transacciones esta adaptado para comenzar, abortar y comprometer transacciones y ejecutar operaciones de lectura y escritura tras la peticion de sus aplicaciones conectadas;
El gestor de transacciones soporta las operaciones: conexion, comienzo de transaccion, lectura, escritura, commit y aborto. Las operaciones de transaccion de conexion, comienzo, commit no tienen parametros. La operacion de lectura tiene como parametro una consulta de solo lectura. La operacion de escritura tiene como parametro una consulta de actualizacion (es decir, una consulta que realiza una o mas actualizaciones: inserciones, deleciones y modificaciones, y posiblemente algunas lecturas);
- en el que el servidor de commit esta adaptado para enviar a cada gestor de transacciones etiquetas desde una secuencia ordenada, de manera que, cada etiqueta solo se envfa a un gestor de transacciones, las etiquetas se envfan por el servidor de commit o bien de manera proactiva o bien de manera reactiva tras la peticion de gestores de transaccion.
- en el que el servidor de snapshot esta adaptado para:
1. Recibir las etiquetas usadas y descartadas.
El servidor de snapshot recibe etiquetas. Estas etiquetas podnan haberse descartado (es decir, producirse por el servidor de commit pero no usarse para etiquetar ninguna transaccion de actualizacion) o comprometido (es decir, las escrituras de la transaccion de actualizacion son duraderas y legibles desde el gestor de datos con una snapshot con una etiqueta igual que o posterior a su etiqueta comprometida).
2. Notificar etiquetas de snapshot en orden no decreciente de manera que para cada etiqueta producida ha recibido todas las etiquetas iguales o inferiores a ella o bien de manera proactiva o bien de manera reactiva tras la peticion de gestores de transaccion.
El servidor de snapshot proporciona etiquetas de snapshot en orden no decreciente. Cualquier etiqueta de snapshot, S, proporcionada por el servidor de snapshot garantiza que el servidor de snapshot ha recibido todas las etiquetas inferiores a S. El servidor de snapshot elimina periodicamente un conjunto de etiquetas de manera que el conjunto es contiguo, son mas antiguas que el resto de las etiquetas almacenadas y hay una etiqueta contigua a la mas antigua de ellas.
- En el que cada gestor de transacciones tambien esta adaptado para:
1. Asignar como etiqueta de comienzo para comenzar una transaccion una, entre las obtenidas desde el servidor de snapshot, posterior a o igual que la ultima usada para la transaccion anterior.
El gestor de transacciones esta adaptado para obtener periodicamente etiquetas de snapshot desde el servidor de snapshot o pedirlas explfcitamente. Cuando una aplicacion se conecta a un gestor de transacciones, el gestor de transacciones asocia a la aplicacion un identificador de conexion unico que se almacena localmente y se devuelve como resultado de la operacion de conexion. Tras la invocacion de la operacion de comienzo por una aplicacion, un gestor de transacciones la asocia a un identificador de transacciones unico, asocia la transaccion a un gestor de datos y selecciona una etiqueta de comienzo inferior que o igual a la ultima etiqueta de snapshot recibida desde el servidor de snapshot (normalmente la ultima recibida desde el servidor de snapshot) y almacena en una tabla de transacciones local el identificador de transacciones, el identificador de conexion, la etiqueta de comienzo y el identificador del gestor de datos.
Periodicamente, uno de los gestores de transaccion recoge del resto de los gestores de transaccion la etiqueta
5
10
15
20
25
30
35
40
45
50
de comienzo mas antigua local para todas las transacciones que gestiona cada uno de ellos. Tras la recepcion de estas etiquetas, obtiene la mas antigua entre ellas y notifica a todos los gestores de conflictos y todos los gestores de datos que esta etiqueta es la snapshot mas antigua de una transaccion activa;
2. Asignar como etiqueta de commit a una transaccion de actualizacion dispuesta para comprometer una de las etiquetas no usadas recibidas desde el servidor de commit, marcandola como usada.
Un gestor de transacciones esta adaptado para obtener periodicamente un conjunto de etiquetas de commit desde el servidor de commit (en modo proactivo) o para pedirlas explfcitamente al servidor de commit (en modo reactivo). Cada gestor de transacciones periodicamente notifica al servidor de snapshot las etiquetas de commit que se han descartado y las etiquetas de commit de transacciones comprometidas. La operacion de transaccion de commit indica el identificador de transacciones y la etiqueta de commit.
3. Transferir cada operacion de lectura con la etiqueta de comienzo a un gestor de datos.
La operacion de lectura es una operacion de lectura arbitraria que podna leer cero o mas elementos de datos y devolver un conjunto de resultados (que podnan estar vados). Un gestor de transacciones tras recibir una invocacion de operacion de lectura desde una aplicacion transfiere la operacion al gestor de datos asociado a la transaccion. El gestor de transacciones tras recibir el resultado de la operacion de escritura transfiere los resultados a la aplicacion.
4. Tras completarse una transaccion, enviar una peticion de registro con todos los cambios realizados por la transaccion a un logger.
Un gestor de transacciones tras recibir una invocacion de operacion de commit desde una aplicacion comprueba si la transaccion realizo alguna actualizacion o no. Si la transaccion no realizo ninguna actualizacion, la informacion sobre la transaccion se elimina, la operacion de commit se invoca en el gestor de datos asociado a esa transaccion, y finalmente el control se devuelve a la aplicacion. Si la aplicacion realizo al menos una actualizacion, el gestor de transacciones toma una etiqueta de commit no usada y la asocia a la transaccion que esta comprometiendose, almacenandose en la tabla de transacciones. Entonces, en paralelo envfa todas las actualizaciones almacenadas a un logger y tambien invoca en paralelo la operacion de commit en el gestor de datos asociado. Cuando el logger responde se devuelve el control a la aplicacion y el gestor de transacciones almacena que la transaccion es duradera en la tabla de transacciones y responde a la aplicacion que la transaccion se ha comprometido. Cuando la operacion de commit devuelve desde el gestor de datos, el gestor de transacciones almacena en la tabla de transacciones que la transaccion es legible. Cuando una transaccion es tanto duradera como legible, entonces el gestor de transacciones almacena en la tabla de transacciones que la transaccion esta comprometida.
5. Tras la notificacion de commit desde el logger, notificar la aplicacion sobre el commit de transaccion.
De este modo, las notificaciones de commit a las aplicaciones se realizan en cuanto la transaccion es duradera independientemente de que sus escrituras se hayan completado, cuando el logger notifica al gestor de transacciones sobre la durabilidad de la transaccion una vez que la durabilidad satisface un nivel de durabilidad y, solo entonces, el gestor de transacciones notifica a la aplicacion sobre el commit de transaccion.
- En el que cada logger esta adaptado para:
1. Configurarse con un nivel de durabilidad que determina si la notificacion de durabilidad puede darse cuando la peticion de registro se ha almacenado o bien en la memoria o bien en almacenamiento persistente del logger.
Esta peticion de registro contiene el conjunto de escrituras, el identificador de transacciones y la etiqueta de commit de transaccion. Cada logger podna replicarse, es decir, un conjunto de loggers que almacenan la misma copia de actualizaciones. El logger puede configurarse con diferentes niveles de durabilidad que determinan cuando devolver desde la peticion de registro.
Si se usa un logger individual, hay dos posibles niveles de durabilidad: cuando el logger ha almacenado la peticion de registro en memoria y cuando el logger ha almacenado en almacenamiento persistente la peticion. Si el logger se replica, entonces el nivel de durabilidad determina que fraccion de loggers debe tener la peticion de registro almacenada en memoria y que fraccion de loggers debe tener la peticion de registro almacenada en almacenamiento persistente antes de notificar que la peticion de registro se ha hecho duradera.
2. Recibir la peticion de registro con el conjunto de cambios realizados por una transaccion y almacenarlos en memoria y en almacenamiento persistente.
Un gestor de transacciones envfa todas las actualizaciones almacenadas de una transaccion a un logger.
3. Notificar al gestor de transacciones sobre la durabilidad de la transaccion cuando la durabilidad satisfaga el nivel de durabilidad configurado.
5
10
15
20
25
30
35
40
45
50
Cuando la peticion de registro es duradera segun su configuracion, el logger notifica sobre la durabilidad de la transaccion indicando su identificador de transacciones.
- En el que cada gestor de conflictos esta adaptado para:
1. Ser responsable de detectar conflictos para un subconjunto de claves.
2. Recibir la clave de elementos actualizados etiquetados con la etiqueta de comienzo de transaccion.
Un gestor de conflictos recibe notificaciones sobre: escrituras sobre datos con claves que gestiona (notificacion de actualizacion), completitud de transacciones de actualizacion (o bien comprometidas o bien abortadas) y la etiqueta de comienzo mas antigua de transacciones activas, es decir, transacciones que han comenzado pero que no se han completado. Una notificacion de actualizacion contiene al menos la clave del dato escrito, el identificador de la transaccion de actualizacion y la etiqueta de comienzo de la transaccion.
3. Tras la recepcion de una clave de un elemento actualizado, almacenar la clave, el identificador de transacciones y su etiqueta de comienzo y comprobar si la misma clave se ha actualizado por cualquier transaccion concurrente.
Tras una notificacion de actualizacion, el gestor de conflictos comprueba si hay cualquier actualizacion asociada a la misma clave desde una transaccion concurrente (dos transacciones son concurrentes si ambas han comenzado y ninguna se ha completado, o si la etiqueta de comienzo de una transaccion esta entre la etiqueta de comienzo y la de commit de una transaccion comprometida) con la asociada a la actualizacion notificada.
a. Si la comprobacion es positiva, el gestor de conflictos esta adaptado para replicar el gestor de transacciones correspondiente con una notificacion de aborto y tambien para almacenar esta decision.
Si hay una actualizacion en conflicto almacenada, el gestor de conflictos notifica el aborto de una de las dos transacciones en conflicto y mantiene la informacion desde la transaccion que no se ha abortado, y descarta la informacion de la transaccion abortada.
b. Si la comprobacion es negativa, esta adaptado para almacenar el identificador de transacciones, la clave del elemento actualizado y la etiqueta de comienzo de transaccion.
Si no hay actualizacion en conflicto almacenada, almacena el identificador de transacciones, la clave y la etiqueta de comienzo de la transaccion de actualizacion. Una notificacion de completitud de transaccion contiene al menos, el identificador de transacciones, el desenlace de la transaccion (commit o aborto) y si la transaccion se ha comprometido, su etiqueta de commit.
4. Recibir la notificacion de aborto de transacciones abortadas.
5. Tras la recepcion de una notificacion de aborto de una transaccion, esta adaptado para eliminar la informacion sobre la transaccion.
Un gestor de conflictos tras recibir una notificacion de completitud de transaccion del aborto de una transaccion elimina todas las actualizaciones almacenadas con el identificador de transacciones recibido.
6. Recibir la notificacion de commit de transacciones comprometidas con su etiqueta de commit.
7. Tras la recepcion de una notificacion de commit de una transaccion, esta adaptado para almacenar su identificador de transacciones y la etiqueta de commit.
Un gestor de conflictos tras recibir una notificacion de completitud de transaccion del commit de una transaccion anade la etiqueta de commit a todas las actualizaciones almacenadas con el mismo identificador de transacciones.
- En el que cada gestor de datos esta adaptado para:
1. Almacenar los elementos de datos correspondientes a un subconjunto de claves.
2. Tras recibir una operacion de escritura o lectura desde un gestor de transacciones, transferir las operaciones de escritura o lectura a los gestores de datos responsables de los datos que tienen acceso y recoger los resultados devolviendolos al gestor de transacciones que realiza la peticion.
Tras recibir una operacion de lectura o escritura, el gestor de datos la traslada a un plan de consulta. Este plan de consulta implica una o mas operaciones de lectura o escritura y la computacion del resultado final de la operacion de lectura o escritura. El gestor de datos esta adaptado para ejecutar el plan de consulta enviando las operaciones de lectura y escritura a uno o mas gestores de datos y combinando los resultados recibidos. Las operaciones de lectura realizadas por cada gestor de datos implicado se realizan sobre la snapshot indicada por la etiqueta de comienzo. El gestor de datos computa el resultado final de la operacion de lectura o escritura y
5
10
15
20
25
30
35
40
45
50
devuelve el conjunto de resultados resultante. Cada elemento en el conjunto de resultados se identifica con su etiqueta de commit.
3. Realizar lecturas dada una etiqueta de comienzo de transaccion y proporcionar las ultimas versiones comprometidas de los elementos de datos ^dos con una etiqueta de commit igual que o anterior a la etiqueta de comienzo.
El gestor de datos, tras recibir una operacion de lectura devuelve el ultimo elemento de datos con una etiqueta de commit igual o anterior a la etiqueta de comienzo.
4. Realizar escrituras en una version privada de los datos visibles solo para operaciones de lectura desde la transaccion de escritura.
El gestor de datos, tras recibir una operacion de escritura la ejecuta sobre los gestores de datos responsables de los datos que tienen acceso. Los gestores de datos controlan que gestores de datos han realizado escrituras para cada transaccion. El gestor de datos responsable de la clave notifica al gestor de conflictos responsable de esa clave sobre la actualizacion y realiza la escritura en una version privada del elemento y lo identifica con el identificador de transacciones. Esta version privada solo sera legible para la transaccion de actualizacion que realiza la escritura. Si la transaccion de actualizacion lee mas tarde la clave de este elemento, leera el ultimo elemento escrito mediante la transaccion en la version privada. Si el gestor de conflictos no detecto un conflicto, devuelve la operacion. Si hubo un conflicto, devuelve que se aborto la transaccion. El gestor de datos que recibio la operacion de escritura devuelve el resultado recibido.
5. Tras comprometer la transaccion, etiquetar todas las versiones privadas de la transaccion con una etiqueta de commit de transaccion y hacerlas publicas.
El gestor de datos identifica cada version privada con la etiqueta de commit indicada en la operacion de commit haciendolas publicas y las devuelve.
La presente invencion tambien tiene en cuenta el diseno de un metodo para procesar transacciones que funcionan en un sistema de gestion transaccional tal como se describio anteriormente, en el que dicho metodo comprende los elementos del sistema que interaccionan entre sf de tal manera que:
- Las transacciones se comprometen de manera asmcrona y en paralelo a medida que se acepta cada peticion de commit por el gestor de transacciones en cualquier momento y en cualquier orden y se procesan inmediatamente sin esperar a que se complete ninguna operacion de comienzo o commit, asignando como etiqueta de commit una etiqueta de commit no usada de las obtenidas desde el servidor de commit,
- Las transacciones se comienzan sin bloqueo a medida que se acepta cada peticion de comienzo de aplicacion por el gestor de transacciones en cualquier momento y en cualquier orden, asignando como etiqueta de comienzo para comenzar una transaccion, una, entre las etiquetas obtenidas desde el servidor de snapshot, que es igual a o posterior a la ultima usada,
- La consistencia transaccional se garantiza haciendo legibles solo las snapshots correspondientes a prefijos libres de huecos de transacciones de actualizacion que son a la vez duraderos y cuyas escrituras se han completado, a medida que el gestor de datos
o realiza lecturas sobre la snapshot indicada por la etiqueta de comienzo de transaccion dada,
o proporciona las ultimas versiones comprometidas de los elementos de datos lefdos con una etiqueta de
commit igual o anterior,
o y realiza escrituras de elemento en una version privada de los datos visibles solo para operaciones de lectura desde la transaccion de escritura.
Como sumario de la invencion, comprende un sistema y un metodo para el procesamiento de transaccion descentralizado que reduce la contencion mediante varias tecnicas. Primero, el sistema de gestion transaccional se descompone en varios componentes que pueden escalarse y/o ampliarse independientemente y de manera componible. Segundo, las transacciones se comprometen en paralelo sin bloquearse entre sf. Tercero, las aplicaciones pueden avanzar cuando las actualizaciones de transacciones son duraderas aunque las escrituras de la transaccion no se hayan completado. Cuarto, la consistencia transaccional se garantiza haciendo legibles solo prefijos libres de huecos de transacciones de actualizacion comprometidas, sin bloquear el commit de nuevas transacciones. Quinto, la consistencia de sesion se garantiza retrasando el comienzo de una nueva transaccion hasta que sea legible la snapshot de cualquier transaccion de actualizacion anterior en la misma sesion.
Descripcion de las figuras
Estas y otras caractensticas y ventajas de la invencion se entenderan claramente en vista de la descripcion detallada de la invencion que se vuelve evidente a partir de una realizacion preferida de la invencion, facilitada solo
5
10
15
20
25
30
35
40
como ejemplo y no siendo limitante de la misma, con referencia a los dibujos.
Figura 1 En esta figura se muestra un ejemplo del sistema que trabaja tal como se describe en una vista
que muestra los siguientes elementos y acciones representados en modo secuencial en una lmea cronologica.
Figura 2 En esta figura se muestra una representacion de un momento en la transaccion en el que el
servidor de snapshot envfa una etiqueta de comienzo a un gestor de transacciones.
Figura 3 En esta figura se muestra una representacion de un momento en la transaccion en el que un
gestor de transacciones envfa un conjunto de etiquetas usadas y no usadas al servidor de snapshot.
Figura 4 En esta figura se muestra una representacion de un momento en la transaccion en el que el
servidor de commit envfa una etiqueta de commit al gestor de transacciones.
Descripcion detallada de la invencion
Se pretende que los terminos “componente”, “gestor”, “servidor” y “sistema” tal como se usan en esta invencion se refieran a una entidad relacionada con ordenadores, ya sea hardware, una combinacion de hardware y software, software, o software en ejecucion. Por ejemplo, un componente puede ser, pero sin limitarse a, un proceso que se ejecuta en un procesador, un procesador, un objeto, un ejecutable, un hilo de ejecucion, un programa y/o un ordenador. Una aplicacion que se ejecuta en un servidor y el servidor pueden ser un componente. Uno o mas componentes pueden residir dentro de un proceso y/o hilo de ejecucion, y un componente puede localizarse en un ordenador y/o distribuirse entre dos o mas ordenadores o nodos.
El sistema de gestion transaccional comprende el siguiente conjunto de componentes: servidor de commit, servidor de snapshot, gestor de transacciones, logger, gestor de conflictos y gestor de datos. Una o mas aplicaciones acceden al sistema de gestion transaccional directa o indirectamente para gestionar sus datos con garantfas transaccionales.
Una forma en la que los elementos se comunican entre sf se representa en la figura 1 donde puede observarse como se gestiona una transaccion en una lmea cronologica en caso de ausencia de conflictos. Estan representados los siguientes elementos;
0. Aplicacion
1. Gestor de transacciones
2. Gestor de datos
3. Logger
4. Servidor de snapshot
5. Servidor de commit
6. Gestor de conflictos
Estan representadas las siguientes acciones:
A. Comienzo de peticion de transaccion desde la aplicacion
B. Asignacion de etiqueta de comienzo
C. Operacion de lectura
D. Transferencia de operacion de lectura al gestor de datos
E. Operacion de escritura
F. Transferencia de operacion de escritura al gestor de datos
G. Comprobacion de conflictos
H. Ningun conflicto detectado
I. Notificacion de actualizaciones
J. Peticion de transaccion de commit desde la aplicacion
5
10
15
20
25
30
35
40
45
K. Asignacion de etiqueta de commit
L. Peticion de registro
M. Confirmacion de durabilidad al gestor de transacciones
N. Confirmacion de commit a la aplicacion
O. Commit (hace publicas las actualizaciones)
P. Confirmacion de legibilidad
Q. Etiqueta de comienzo desde el servidor de snapshot
R. Etiquetas usadas y no usadas
S. Etiqueta de commit
Una realizacion alternativa del sistema amplfa los sistemas mencionados anteriormente tal como sigue. Los gestores de transaccion notifican periodicamente al servidor de commit sobre cuantas transacciones de actualizacion han ejecutado en el ultimo periodo (por ejemplo, tras recibir un conjunto de etiquetas de commit desde el servidor de commit). El servidor de commit computa la ultima tasa de transaccion conocida desde cada gestor de transacciones y genera un conjunto de etiquetas para cada uno de ellos, numero que es una funcion de sus tasas de transaccion de actualizacion. Alternativamente, el servidor de commit podna tener en cuenta las tasas de evolucion de la transaccion a lo largo del tiempo para estimar cual sera la tasa de transaccion en el siguiente periodo y adaptar la proporcion de etiquetas para cada gestor de transacciones por consiguiente. Esta realizacion puede ampliarse adoptando el mismo periodo para la interaccion entre gestores de transaccion y el servidor de snapshot. Al final de cada periodo, el servidor de commit envfa nuevos conjuntos de etiquetas de commit a los gestores de transaccion. Cada gestor de transacciones ademas de notificar al servidor de commit su ultima tasa de transaccion de actualizacion, notifica al servidor de snapshot sobre el conjunto de etiquetas desde el periodo anterior. Es decir, notifican sobre todas las etiquetas de transacciones comprometidas, y todas las etiquetas no usadas. El servidor de snapshot tras recibir la notificacion de uno o mas gestores de transaccion notifica la etiqueta de snapshot actual.
El sistema de gestion transaccional puede usarse para diferentes tipos de arquitecturas de sistemas de gestion de datos tales como una arquitectura de multiples niveles con una capa de servidor de aplicacion y una capa de datos (por ejemplo Java Enterprise Edition), o un sistema de bases de datos, un almacen de clave-valor, un almacen de datos orientados en columna o cualquier otro tipo de almacen de datos.
En otra realizacion preferida, la consistencia de sesion se garantiza retrasando el comienzo de nuevas transacciones desde la propia sesion hasta que las escrituras de transacciones de actualizacion anteriores en la misma sesion son duraderas y completas. Esto se garantiza cuando el gestor de transacciones, tras recibir el comienzo de una transaccion desde una aplicacion que ha ejecutado anteriormente una transaccion de actualizacion, espera para comenzar una nueva transaccion desde esta sesion hasta que la ultima etiqueta de snapshot notificada por el servidor de snapshot es igual a o mayor que la ultima etiqueta de commit de transaccion de actualizacion de la aplicacion. El gestor de transacciones usa tal etiqueta como etiqueta de comienzo para la transaccion.
En otra realizacion preferida de la invencion, se realiza recogida de basura. Para este fin, uno de los gestores de transaccion recoge las etiquetas de comienzo de las transacciones activas mas antiguas de todos los gestores de transaccion y obtiene la etiqueta de comienzo mas antigua entre ellas. Entonces, envfa una notificacion a todos los gestores de conflictos y gestores de datos de la transaccion activa mas antigua. Tras la notificacion de la etiqueta de comienzo mas antigua de transacciones activas en el sistema:
• Cada gestor de conflictos esta adaptado para descartar la informacion sobre cualquier transaccion con una etiqueta de commit anterior;
• Cada gestor de datos esta adaptado para eliminar versiones de datos que no son necesarios. Una clave podna tener asociada una o mas versiones que se ordenan por las etiquetas de commit. Se mantiene la version mas antigua con una etiqueta de commit igual o inferior a la etiqueta de comienzo mas antigua de transacciones activas asf como las ultimas versiones. Se eliminan las versiones anteriores.
Claims (20)
- 51015202530354045REIVINDICACIONESSistema de gestion de datos transaccional distribuido segun un modelo cliente-servidor caracterizado porque- en el lado del servidor el sistema de gestion de datos transaccional se descompone en diferentes componentes que son:o un componente de servidor de commit,o un componente de servidor de snapshot,o al menos dos componentes de gestores de transacciones,o al menos un componente de gestor de conflictos,o al menos un componente logger,o al menos un componente de gestor de datos,en el que diferentes componentes estan asignados a diferentes nodos,- en el lado del cliente, una o mas aplicaciones adaptadas para interaccionar directa o indirectamente con el servidor, estando adaptada cada aplicacion parai. conectarse a un componente de gestor de transacciones,ii. realizar mas de cero interacciones de las etapas siguientes:1. pedir a un componente de gestor de transacciones que comience una transaccion;
- 2. pedir al componente de gestor de transacciones mas de cero operaciones de lectura y escritura,
- 3. pedir al componente de gestor de transacciones que comprometa o aborte la transaccion,iii. recibir una notificacion por el componente de gestor de transacciones de que la transaccion se ha completado o bien comprometiendo o bien abortando,- en el que cada componente de gestor de transacciones esta adaptado para comenzar, abortar y comprometer transacciones y ejecutar operaciones de lectura y escritura tras la peticion de sus aplicaciones conectadas,- en el que el componente de servidor de commit esta adaptado para enviar a cada gestor de transacciones etiquetas desde una secuencia ordenada, de manera que, cada etiqueta solo se envfa a un componente de gestor de transacciones, las etiquetas se envfan por el componente de servidor de commit o bien de manera proactiva o bien de manera reactiva tras la peticion de componentes de gestores de transacciones, en el que esta secuencia ordenada de etiquetas representa la secuencia de transacciones comprometidas,- en el que el componente de servidor de snapshot esta adaptado para:1. recibir las etiquetas usadas y descartadas procedentes de los componentes de gestores de transacciones, en el que las etiquetas descartadas son aquellas etiquetas producidas por el componente de servidor de commit pero no usadas para etiquetar ninguna transaccion de actualizacion y las etiquetas usadas son etiquetas usadas para etiquetar una transaccion de actualizacion cuyas escrituras son duraderas y legibles desde el componente de gestor de datos con una snapshot con una etiqueta igual que o posterior a su etiqueta de commit,
- 2. notificar etiquetas de snapshot a los componentes de gestores de transacciones o bien de manera proactiva o bien de manera reactiva tras la peticion de los componentes de gestores de transacciones, de manera que cualquier etiqueta de snapshot proporcionada por el componente de servidor de snapshot a los componentes de gestores de transacciones garantiza que el componente de servidor de snapshot recibio todas las etiquetas iguales o inferiores a esta etiqueta,- en el que cada componente de gestor de transacciones tambien esta adaptado para:1. asignar como etiqueta de comienzo para comenzar una transaccion una, entre las obtenidas desde el componente de servidor de snapshot, posterior a o igual que la ultima usada para la transaccion anterior,
- 2. asignar como etiqueta comprometida a una transaccion de actualizacion dispuesta a comprometer una51015202530354045de las etiquetas no usadas recibidas desde el componente de servidor de commit, marcandola como usada,
- 3. transferir cada operacion de lectura con la etiqueta de comienzo a un componente de gestor de datos,
- 4. tras completarse una transaccion, enviar una peticion de registro con todos los cambios realizados por la transaccion a un componente logger,
- 5. tras la notificacion de commit desde el componente logger, notificar la aplicacion sobre el commit de transaccion,- en el que cada componente logger esta adaptado para:1. configurarse con un nivel de durabilidad que determina si la notificacion de durabilidad puede darse cuando la peticion de registro se ha almacenado o bien en la memoria o bien en almacenamiento persistente del componente logger,
- 2. recibir la peticion de registro con el conjunto de cambios realizados por una transaccion y almacenarlos en memoria y en almacenamiento persistente,
- 3. notificar al componente de gestor de transacciones sobre la durabilidad de la transaccion cuando la durabilidad satisface el nivel de durabilidad configurado,- en el que cada componente de gestor de conflictos esta adaptado para:1. ser responsable de detectar conflictos para un subconjunto de claves,
- 2. recibir la clave de elementos actualizados etiquetados con la etiqueta de comienzo de transaccion,
- 3. tras la recepcion de una clave de un elemento actualizado, almacenar la clave, el identificador de transacciones y su etiqueta de comienzo y comprobar si la misma clave se ha actualizado por cualquier transaccion concurrente,a. si la comprobacion es positiva, el componente de gestor de conflictos esta adaptado para responder al componente de gestor de transacciones correspondiente con una notificacion de aborto y tambien para almacenar esta decision,b. si la comprobacion es negativa, el esta adaptado para almacenar el identificador de transacciones, la clave del elemento actualizado y la etiqueta de comienzo de transaccion,
- 4. recibir la notificacion de aborto de transacciones abortadas,
- 5. tras la recepcion de una notificacion de aborto de una transaccion, el esta adaptado para eliminar la informacion sobre la transaccion,
- 6. recibir la notificacion de commit de transacciones comprometidas con su etiqueta de commit,
- 7. tras la recepcion de una notificacion de commit de una transaccion, el esta adaptado para almacenar su identificador de transacciones y etiqueta de commit,- en el que cada componente de gestor de datos esta adaptado para:1. almacenar los elementos de datos correspondientes a un subconjunto de claves,
- 2. tras recibir una operacion de escritura o lectura desde un componente de gestor de transacciones, transferir las operaciones de escritura o lectura a los componentes de gestores de datos responsables de los datos que tienen acceso y recoger los resultados devolviendolos al componente de gestor de transacciones que realiza la peticion,
- 3. realizar lecturas dada una etiqueta de comienzo de transaccion y proporcionar las ultimas versiones comprometidas de los elementos de datos lefdos con una etiqueta de commit igual que o anterior a la etiqueta de comienzo,
- 4. realizar escrituras en una version privada de los datos visibles solo para operaciones de lectura desde la transaccion de escritura,
- 5. tras verificar la transaccion, etiquetar todas las versiones privadas de la transaccion con la etiqueta de commit de transaccion y hacerlas publicas.Sistema segun la reivindicacion 1, en el que:510152025303540a. cada componente de gestor de transacciones esta adaptado para enviar periodicamente al componente de servidor de commit el numero de transacciones de actualizacion comprometidas en al menos un periodo pasado,b. el componente de servidor de commit esta adaptado para enviar periodicamente a cada componente de gestor de transacciones un subconjunto de etiquetas que es una funcion de la fraccion de transacciones de actualizacion comprometidas enviadas por el componente de gestor de transacciones.Sistema segun la reivindicacion 1, en el que si la aplicacion comprometio anteriormente de manera satisfactoria cualquier transaccion de actualizacion, el componente de gestor de transacciones esta adaptado para esperar para comenzar una nueva transaccion desde esta sesion hasta que la ultima etiqueta de snapshot notificada por el componente de servidor de snapshot es igual a o mayor que la ultima etiqueta de commit de transaccion de actualizacion de la aplicacion.Sistema segun la reivindicacion 1, en el que al menos uno de los componentes de gestores de transacciones esta adaptado para recoger las etiquetas de comienzo de las transacciones activas mas antiguas en todos los componentes de gestores de transacciones obteniendo la etiqueta de comienzo mas antigua entre ellas y enviando la notificacion a todos los componentes de gestores de conflictos y componentes de gestores de datos y en el que, cada componente de gestor de conflictos, esta adaptado para descartar la informacion sobre cualquier transaccion con una etiqueta de commit anterior; y, cada componente de gestor de datos esta adaptado para eliminar aquellas versiones de datos que son anteriores a la version mas antigua con una etiqueta de commit igual o inferior a la etiqueta de comienzo mas antigua de transacciones activas.Metodo para procesar transacciones que funcionan en el sistema de gestion de datos transaccional distribuido segun la reivindicacion 1, en el que dicho metodo comprende los elementos del sistema que interaccionan entre sf de tal manera que:las transacciones se comprometen de manera asmcrona y en paralelo a medida que se acepta cada peticion de commit por el componente de gestor de transacciones en cualquier momento y en cualquier orden y se procesan inmediatamente sin esperar a que se complete ninguna otra operacion de comienzo o commit, asignando como etiqueta de commit una etiqueta de commit no usada de las obtenidas desde el componente de servidor de commit,- las transacciones se comienzan sin bloqueo a medida que se acepta cada peticion de comienzo de aplicacion por el componente de gestor de transacciones en cualquier momento y en cualquier orden, asignando como etiqueta de comienzo para comenzar una transaccion una, entre las etiquetas obtenidas desde el componente de servidor de snapshot, que es igual a o posterior a la ultima usada,- la consistencia transaccional se garantiza haciendo legibles solo las snapshots correspondientes a prefijos libres de huecos de transacciones de actualizacion que son a la vez duraderas y cuyas escrituras se han completado, a medida que el componente de gestor de datoso realiza lecturas sobre la snapshot indicada por la etiqueta de comienzo de transaccion dada,o proporciona las ultimas versiones comprometidas de los elementos de datos lefdos con una etiqueta de commit igual o anterior,o y realiza escrituras de elemento en una version privada de los datos visibles solo para operaciones de lectura desde la transaccion de escritura.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201161561508P | 2011-11-18 | 2011-11-18 | |
| US201161561508P | 2011-11-18 | ||
| PCT/EP2012/072811 WO2013072451A2 (en) | 2011-11-18 | 2012-11-16 | System and method for highly scalable decentralized and low contention transactional processing x |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| ES2584102T3 true ES2584102T3 (es) | 2016-09-23 |
Family
ID=47216249
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| ES12788505.1T Active ES2584102T3 (es) | 2011-11-18 | 2012-11-16 | Sistema y método para procesamiento transaccional de baja contención y descentralizado altamente escalable |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US9760597B2 (es) |
| EP (1) | EP2780832B1 (es) |
| ES (1) | ES2584102T3 (es) |
| WO (1) | WO2013072451A2 (es) |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9317379B2 (en) | 2014-01-24 | 2016-04-19 | International Business Machines Corporation | Using transactional execution for reliability and recovery of transient failures |
| GB2524540A (en) * | 2014-03-26 | 2015-09-30 | Ibm | Replication of a relational database |
| US10678445B2 (en) | 2015-06-10 | 2020-06-09 | Microsoft Technology Licensing, Llc | Recovery in data centers |
| US10706019B2 (en) * | 2015-09-22 | 2020-07-07 | Sap Se | Database processing after a lock condition |
| EP3373148A4 (en) * | 2015-11-05 | 2019-05-15 | Murakumo Corporation | DATABASE SYSTEM, TRANSACTION MANAGEMENT NODES, PROCEDURES AND PROGRAM |
| US10417218B2 (en) * | 2015-12-23 | 2019-09-17 | Intel Corporation | Techniques to achieve ordering among storage device transactions |
| US10951706B2 (en) * | 2016-12-09 | 2021-03-16 | Google Llc | High-throughput algorithm for multiversion concurrency control with globally synchronized time |
| CN107590028B (zh) * | 2017-09-14 | 2021-05-11 | 广州华多网络科技有限公司 | 一种信息处理的方法、服务器 |
| US11281451B2 (en) | 2017-12-06 | 2022-03-22 | Vmware, Inc. | Distributed backup and restoration in virtualized computing environments |
| US10545750B2 (en) * | 2017-12-06 | 2020-01-28 | Vmware, Inc. | Distributed upgrade in virtualized computing environments |
| US10831663B2 (en) * | 2018-12-10 | 2020-11-10 | International Business Machines Corporation | Tracking transactions using extended memory features |
| US11921701B2 (en) * | 2019-02-12 | 2024-03-05 | Ebay Inc. | Global distributed transactions across microservices |
| US11997190B2 (en) | 2019-06-05 | 2024-05-28 | Mastercard International Incorporated | Credential management in distributed computing system |
| US11032381B2 (en) * | 2019-06-19 | 2021-06-08 | Servicenow, Inc. | Discovery and storage of resource tags |
| EP3816915A1 (en) | 2019-11-04 | 2021-05-05 | Mastercard International Incorporated | Monitoring in distributed computing system |
| US11928097B2 (en) * | 2021-09-20 | 2024-03-12 | Oracle International Corporation | Deterministic semantic for graph property update queries and its efficient implementation |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7206805B1 (en) * | 1999-09-09 | 2007-04-17 | Oracle International Corporation | Asynchronous transcription object management system |
| US8356007B2 (en) * | 2010-10-20 | 2013-01-15 | Microsoft Corporation | Distributed transaction management for database systems with multiversioning |
| US8935205B2 (en) * | 2011-11-16 | 2015-01-13 | Sap Ag | System and method of performing snapshot isolation in distributed databases |
-
2012
- 2012-11-16 ES ES12788505.1T patent/ES2584102T3/es active Active
- 2012-11-16 EP EP12788505.1A patent/EP2780832B1/en active Active
- 2012-11-16 US US14/908,892 patent/US9760597B2/en active Active
- 2012-11-16 WO PCT/EP2012/072811 patent/WO2013072451A2/en active Application Filing
Also Published As
| Publication number | Publication date |
|---|---|
| US20160179876A1 (en) | 2016-06-23 |
| EP2780832A2 (en) | 2014-09-24 |
| WO2013072451A2 (en) | 2013-05-23 |
| EP2780832B1 (en) | 2016-05-25 |
| WO2013072451A3 (en) | 2014-01-16 |
| US9760597B2 (en) | 2017-09-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| ES2584102T3 (es) | Sistema y método para procesamiento transaccional de baja contención y descentralizado altamente escalable | |
| US20220276994A1 (en) | Multi-database log with multi-item transaction support | |
| AU2019200967B2 (en) | Multi-database log with multi-item transaction support | |
| US9619278B2 (en) | Log-based concurrency control using signatures | |
| US9619544B2 (en) | Distributed state management using dynamic replication graphs | |
| US20220197896A1 (en) | Transactional database layer above a distributed key/value store | |
| US10282228B2 (en) | Log-based transaction constraint management | |
| US10430298B2 (en) | Versatile in-memory database recovery using logical log records | |
| US9529882B2 (en) | Coordinated suspension of replication groups | |
| US20180322158A1 (en) | Changing concurrency control modes | |
| US12032560B2 (en) | Distributed transaction execution management in distributed databases | |
| WO2019220269A1 (en) | System and method for a distributed database | |
| Assiri et al. | Approximate count and queue objects in transactional memory | |
| Diegues et al. | Bumper: Sheltering distributed transactions from conflicts | |
| Lykhenko | Efficient implementation of causal consistent transactions in the cloud | |
| Gonçalves | Multi-Value Distributed Key-Value Stores | |
| Kashi | Eventual Durability of ACID Transactions in Database Systems | |
| Tang et al. | Harp: towards enhancing data recency for eventually consistent data stores |