{"id":30878,"date":"2019-10-31T21:37:56","date_gmt":"2019-10-31T18:37:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/tranzaktsii-i-mehanizmy-ih-kontrolya\/"},"modified":"2019-10-31T21:37:56","modified_gmt":"2019-10-31T18:37:56","slug":"tranzaktsii-i-mehanizmy-ih-kontrolya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","title":{"rendered":"Transacciones y mecanismos de control","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Transacciones<\/h2>\n

<\/p>\n

Se denomina transacci\u00f3n a una secuencia de operaciones sobre datos que tiene un inicio y un final.<\/h4>\n

\nUna transacci\u00f3n es la ejecuci\u00f3n secuencial de operaciones de lectura y escritura. El final de la transacci\u00f3n puede ser la confirmaci\u00f3n de los cambios (commit) o la reversi\u00f3n de los cambios (rollback). En el contexto de bases de datos, una transacci\u00f3n consiste en varias consultas que se tratan como una \u00fanica consulta.<\/p>\n

Las transacciones deben cumplir con las propiedades ACID.<\/h4>\n

\nAtomicidad. La transacci\u00f3n se ejecuta completamente o no se ejecuta en absoluto.<\/p>\n

Consistencia. Al finalizar la transacci\u00f3n no se deben violar las restricciones impuestas a los datos (por ejemplo, constraints en bases de datos). La consistencia implica que el sistema debe pasar de un estado correcto a otro estado correcto.<\/p>\n

Aislamiento. Las transacciones que se ejecutan en paralelo no deben influir unas en otras, por ejemplo, no deben modificar datos que utiliza otra transacci\u00f3n. El resultado de la ejecuci\u00f3n de transacciones en paralelo debe ser el mismo que si las transacciones se ejecutaran secuencialmente.<\/p>\n

Durabilidad. Despu\u00e9s de la confirmaci\u00f3n, los cambios no deben perderse.
\n<\/a><\/noindex><\/p>\n

Registro de transacciones<\/h2>\n

<\/p>\n

El registro guarda los cambios realizados por las transacciones, asegurando la atomicidad y durabilidad de los datos en caso de fallo del sistema.<\/h4>\n

\nEl registro contiene los valores que los datos ten\u00edan antes y despu\u00e9s de ser modificados por la transacci\u00f3n. La estrategia de Write-ahead log obliga a a\u00f1adir al registro informaci\u00f3n sobre los valores anteriores antes del inicio y sobre los valores finales despu\u00e9s de finalizar la transacci\u00f3n. En caso de un paro inesperado del sistema, la base de datos lee el log en orden inverso y revierte los cambios realizados por las transacciones. Al encontrar una transacci\u00f3n interrumpida, la base de datos la ejecuta y registra los cambios realizados. Al estar en el estado en el momento de la falla, la base de datos lee el log en el orden correcto y aplica los cambios realizados por las transacciones. De este modo, se preserva la durabilidad de las transacciones que ya se hab\u00edan confirmado y la atomicidad de la transacci\u00f3n interrumpida.<\/p>\n

La simple repetici\u00f3n de transacciones err\u00f3neas no es suficiente para la recuperaci\u00f3n. <\/p>\n

Ejemplo. El saldo del usuario es de 500$ y el usuario decide retirar ese dinero a trav\u00e9s de un cajero autom\u00e1tico. Se realizan dos transacciones. La primera lee el valor del saldo y, si hay suficientes fondos, entrega el dinero al usuario. La segunda resta la cantidad necesaria del saldo. Supongamos que hubo una falla en el sistema y la primera operaci\u00f3n no se complet\u00f3, mientras que la segunda s\u00ed se ejecut\u00f3. En este caso, no podemos volver a entregar dinero al usuario sin restaurar el sistema a su estado inicial con un saldo positivo.<\/i><\/p>\n

Niveles de aislamiento<\/h2>\n

<\/p>\n

Lectura de datos fijos (Read Committed)<\/h4>\n

\nEl problema de la lectura sucia (Dirty Read) radica en que una transacci\u00f3n puede leer un resultado intermedio de otra transacci\u00f3n.<\/p>\n

Ejemplo. El saldo inicial es de 0$. T1 a\u00f1ade 50$ al saldo. T2 lee el saldo (50$). T1 cancela los cambios y finaliza. T2 contin\u00faa ejecut\u00e1ndose con datos incorrectos sobre el saldo.<\/i><\/p>\n

La soluci\u00f3n es la lectura de datos fijos (Read Committed), que proh\u00edbe leer datos modificados por una transacci\u00f3n. Si la transacci\u00f3n A ha modificado un conjunto de datos, la transacci\u00f3n B debe esperar a que la transacci\u00f3n A finalice para acceder a esos datos.<\/p>\n

Lectura repetible (Repeatable Read)<\/h4>\n

\nEl problema de las actualizaciones perdidas (Lost Updates). T1 guarda los cambios sobre los cambios de T2.<\/p>\n

Ejemplo. El saldo inicial es de 0$ y dos transacciones suman simult\u00e1neamente al saldo. T1 y T2 leen un saldo igual a 0$. Luego, T2 suma 200$ a 0$ y guarda el resultado. T1 suma 100$ a 0$ y guarda el resultado. El saldo final es de 100$ en lugar de 300$.<\/i><\/p>\n

El problema de la lectura no repetible (Unrepeatable read). Volver a leer los mismos datos devuelve valores diferentes.<\/p>\n

Ejemplo. T1 lee un saldo de 0$. Luego T2 a\u00f1ade 50$ al saldo y finaliza. T1 vuelve a leer los datos y encuentra una discrepancia con el resultado anterior.<\/i><\/p>\n

La lectura repetible (Repeatable Read) garantiza que una nueva lectura devolver\u00e1 el mismo resultado. Los datos le\u00eddos por una transacci\u00f3n no se pueden modificar en otras hasta que la transacci\u00f3n se complete. Si la transacci\u00f3n A ha le\u00eddo un conjunto de datos, la transacci\u00f3n B debe esperar a que finalice la transacci\u00f3n A antes de acceder a esos datos.<\/p>\n

Lectura ordenada (Serializable)<\/h4>\n

\nEl problema de las lecturas fantasma (Phantom Reads). Dos consultas que seleccionan datos seg\u00fan alguna condici\u00f3n devuelven diferentes valores.<\/p>\n

Ejemplo. T1 solicita el n\u00famero total de usuarios cuyo saldo es mayor a 0$ pero menor a 100$. T2 deduce 1$ del saldo de un usuario con 101$. T1 repite la consulta.<\/i><\/p>\n

Lectura ordenada (Serializable). Las transacciones se ejecutan como si fueran completamente secuenciales. Se proh\u00edbe actualizar y a\u00f1adir registros que se vean afectados por los criterios de la consulta. Si la transacci\u00f3n A solicita todos los datos de la tabla, entonces la tabla queda bloqueada para las dem\u00e1s transacciones hasta que la transacci\u00f3n A finalice.<\/p>\n

Planificador (Scheduler)<\/h2>\n

<\/p>\n

Establece el orden en que se deben ejecutar las operaciones en las transacciones que se llevan a cabo en paralelo.<\/h4>\n

\nProporciona el nivel de aislamiento especificado. Si el resultado de las operaciones no depende de su orden, estas operaciones son conmutativas (Permutable). Las operaciones de lectura y las operaciones sobre diferentes datos son conmutativas. Las operaciones de lectura-escritura y escritura-escritura no son conmutativas. La tarea del planificador es alternar las operaciones realizadas por transacciones paralelas para que el resultado sea equivalente a la ejecuci\u00f3n secuencial de las transacciones.<\/p>\n

Mecanismos de control de tareas en paralelo (Concurrency Control)<\/h2>\n

<\/p>\n

Optimista, basado en la detecci\u00f3n y resoluci\u00f3n de conflictos; pesimista, en prevenir la aparici\u00f3n de conflictos.<\/h4>\n

\nCon el enfoque optimista, varios usuarios obtienen copias de los datos. El primero que complete la edici\u00f3n guarda los cambios, mientras que los dem\u00e1s deben fusionar sus cambios. El algoritmo optimista permite que el conflicto ocurra, pero el sistema debe recuperarse despu\u00e9s del conflicto.<\/p>\n

Con el enfoque pesimista, el primer usuario que captura los datos impide que otros usuarios accedan a ellos. Si los conflictos son raros, tiene sentido elegir la estrategia optimista, ya que proporciona un mayor nivel de paralelismo.<\/p>\n

Bloqueo (Locking)<\/h2>\n

<\/p>\n

Si una transacci\u00f3n bloquea los datos, las dem\u00e1s transacciones que intenten acceder a esos datos deben esperar a que se desbloqueen.<\/h4>\n

\nUn bloque puede aplicarse a una base de datos, tabla, fila o atributo. Un bloqueo compartido (Shared Lock) puede ser impuesto en los mismos datos por varias transacciones, permitiendo a todas las transacciones (incluyendo la que impuso el bloqueo) leer, pero prohibiendo modificaciones y bloqueos exclusivos. Un bloqueo exclusivo (Exclusive Lock) solo puede ser impuesto por una transacci\u00f3n, permitiendo cualquier acci\u00f3n de la transacci\u00f3n que aplic\u00f3 el bloqueo, pero prohibiendo cualquier acci\u00f3n a las dem\u00e1s.<\/p>\n

Se considera un bloqueo mutuo (deadlock) cuando las transacciones quedan en un estado de espera que dura indefinidamente.<\/h4>\n

\nEjemplo. La primera transacci\u00f3n espera la liberaci\u00f3n de los datos bloqueados por la segunda, mientras que la segunda espera la liberaci\u00f3n de los datos bloqueados por la primera.<\/i><\/p>\n

Una soluci\u00f3n optimista al problema de los bloqueos mutuos permite que se produzca el bloqueo, pero luego restaura el sistema retrocediendo una de las transacciones involucradas en el bloqueo mutuo.<\/h4>\n

\nSe realiza una b\u00fasqueda de bloqueos mutuos a intervalos regulares. Una forma de detecci\u00f3n es a trav\u00e9s del tiempo, es decir, considerar que ha ocurrido un bloqueo mutuo si una transacci\u00f3n est\u00e1 en ejecuci\u00f3n durante demasiado tiempo. Cuando se encuentra un bloqueo mutuo, una de las transacciones se retrocede, lo que permite que otras transacciones involucradas en el bloqueo mutuo se completen. La selecci\u00f3n de la v\u00edctima puede basarse en el costo de las transacciones o su antig\u00fcedad (esquemas Wait-Die y Wound-wait). <\/p>\n

A cada transacci\u00f3n T<\/b> se le asigna una marca temporal TS<\/b> que contiene el tiempo de inicio de ejecuci\u00f3n de la transacci\u00f3n.<\/p>\n

Wait-Die. <\/p>\n

Si TS(Ti)<\/b> < TS(Tj)<\/b>, entonces Ti<\/b> espera, de lo contrario Ti<\/b> se retrocede y comienza de nuevo con la misma marca temporal.<\/u><\/p>\n

Si una transacci\u00f3n joven ha adquirido un recurso, y una m\u00e1s antigua solicita el mismo recurso, entonces se permite que la transacci\u00f3n m\u00e1s antigua espere. Si una transacci\u00f3n m\u00e1s antigua ha adquirido un recurso, entonces la transacci\u00f3n joven que solicita ese recurso ser\u00e1 retrocedida.<\/p>\n

Wound-wait. <\/p>\n

Si TS(Ti)<\/b> < TS(Tj)<\/b>, entonces Tj<\/b> se retrocede y comienza de nuevo con la misma marca temporal, de lo contrario Ti<\/b> espera.<\/u><\/p>\n

Si una transacci\u00f3n m\u00e1s joven ha capturado un recurso y una transacci\u00f3n m\u00e1s antigua solicita el mismo recurso, la transacci\u00f3n m\u00e1s joven ser\u00e1 revertida. Si una transacci\u00f3n m\u00e1s antigua ha capturado el recurso, se permite a la transacci\u00f3n m\u00e1s joven que solicita ese recurso esperar. La elecci\u00f3n de la v\u00edctima basada en la antig\u00fcedad previene la aparici\u00f3n de bloqueos mutuos, pero revierte transacciones que no est\u00e1n en estado de bloqueo mutuo. El problema es que las transacciones pueden ser revertidas varias veces, ya que una transacci\u00f3n m\u00e1s antigua puede retener un recurso durante mucho tiempo.<\/p>\n

La soluci\u00f3n pesimista al problema de los bloqueos mutuos no permite que la transacci\u00f3n comience su ejecuci\u00f3n si existe el riesgo de un bloqueo mutuo.<\/h4>\n

\nPara detectar bloqueos mutuos se construye un gr\u00e1fico (gr\u00e1fico de espera, wait-for-graph), cuyos nodos son transacciones, y los arcos est\u00e1n dirigidos desde las transacciones que esperan la liberaci\u00f3n de datos hacia la transacci\u00f3n que ha capturado esos datos. Se considera que ha ocurrido un bloqueo mutuo si el gr\u00e1fico tiene ciclos. La construcci\u00f3n del gr\u00e1fico de espera, especialmente en bases de datos distribuidas, es un procedimiento costoso.<\/p>\n

El bloqueo en dos fases es la prevenci\u00f3n de bloqueos mutuos mediante la captura de todos los recursos utilizados por la transacci\u00f3n al inicio de la misma y la liberaci\u00f3n de estos al final.<\/h4>\n

\nTodas las operaciones de bloqueo deben preceder a la primera operaci\u00f3n de desbloqueo. Tiene dos fases: la Fase de Crecimiento en la que se acumulan capturas y la Fase de Reducci\u00f3n en la que se liberan capturas. Si no es posible capturar uno de los recursos, la transacci\u00f3n comienza de nuevo. Puede darse la situaci\u00f3n en la que una transacci\u00f3n no pueda capturar los recursos requeridos, por ejemplo, si varias transacciones compiten por los mismos recursos.<\/p>\n

El compromiso en dos fases asegura la ejecuci\u00f3n del compromiso en todas las r\u00e9plicas de la base de datos.<\/h4>\n

\nCada base de datos registra la informaci\u00f3n de los datos que ser\u00e1n modificados en un log y responde al coordinador con un OK (Fase de Votaci\u00f3n). Despu\u00e9s de que todos hayan respondido OK, el coordinador env\u00eda una se\u00f1al que obliga a todos a realizar el compromiso. Despu\u00e9s del compromiso, servidores<\/a> respondan OK; si alguno no respondi\u00f3 OK, el coordinador env\u00eda una se\u00f1al de cancelaci\u00f3n de cambios a todos los servidores (Fase de Finalizaci\u00f3n).<\/p>\n

M\u00e9todo de marcas de tiempo.<\/h2>\n

<\/p>\n

Una transacci\u00f3n m\u00e1s antigua se revierte al intentar acceder a datos involucrados en una transacci\u00f3n m\u00e1s joven.<\/h4>\n

\nA cada transacci\u00f3n se le asigna una marca de tiempo TS<\/b> que corresponde al momento de inicio de la ejecuci\u00f3n. Si Ti<\/b> es anterior a Tj<\/b>, entonces TS(Ti)<\/b> < TS(Tj)<\/b>.<\/p>\n

Cuando una transacci\u00f3n se retrocede, se le asigna una nueva marca de tiempo. Cada objeto de datos Q<\/b> involucrado en la transacci\u00f3n se marca con dos etiquetas. W-TS(Q)<\/b> \u2014 la marca de tiempo de la transacci\u00f3n m\u00e1s reciente que ha realizado una escritura sobre Q<\/b>. R-TS(Q)<\/b> \u2014 la marca de tiempo de la transacci\u00f3n m\u00e1s reciente que ha realizado una lectura sobre Q<\/b>.<\/p>\n

Cuando la transacci\u00f3n T<\/b> solicita leer datos Q<\/b> hay dos posibilidades.<\/p>\n

Si TS(T)<\/b> < W-TS(Q)<\/b>, es decir, si los datos han sido actualizados por una transacci\u00f3n m\u00e1s reciente, entonces la transacci\u00f3n T<\/b> se retrocede.<\/u><\/p>\n

Si TS(T)<\/b> >= W-TS(Q)<\/b>, entonces la lectura se lleva a cabo y R-TS(Q)<\/b> se convierte en MAX(R-TS(Q), TS(T))<\/b>.<\/u><\/p>\n

Cuando la transacci\u00f3n T<\/b> solicita modificar los datos Q<\/b> hay dos posibilidades. <\/p>\n

Si TS(T)<\/b> < R-TS(Q)<\/b>, es decir, si los datos ya han sido le\u00eddos por una transacci\u00f3n m\u00e1s reciente y si se produce una modificaci\u00f3n, se generar\u00e1 un conflicto. La transacci\u00f3n T<\/b> se retrocede. <\/u><\/p>\n

Si TS(T)<\/b> < W-TS(Q)<\/b>, es decir, si la transacci\u00f3n intenta sobrescribir un valor m\u00e1s nuevo, la transacci\u00f3n T se retrocede. En los dem\u00e1s casos, la modificaci\u00f3n se realiza y W-TS(Q)<\/b> se convierte en TS(T)<\/b>.<\/u><\/p>\n

No se requiere la costosa construcci\u00f3n de un gr\u00e1fico de espera. Las transacciones m\u00e1s antiguas dependen de las m\u00e1s nuevas, por lo tanto, no hay ciclos en el gr\u00e1fico de espera. No hay bloqueos mutuos, ya que las transacciones no esperan, sino que se retroceden de inmediato. Pueden ocurrir retrocesos en cascada. Si Ti<\/b> se retrocedi\u00f3, y Tj<\/b> ley\u00f3 datos que modific\u00f3 Ti<\/b>, entonces Tj<\/b> tambi\u00e9n debe retroceder. Si en ese momento Tj<\/b> ya se hab\u00eda confirmado, se violar\u00e1 el principio de consistencia.<\/p>\n

Una de las soluciones para los retrocesos en cascada. La transacci\u00f3n realiza todas las operaciones de escritura al final, y las dem\u00e1s transacciones deben esperar a que se complete esta operaci\u00f3n. Las transacciones esperan el compromiso antes de leer.<\/p>\n

La regla de escritura de Thomas \u2014 una variaci\u00f3n del m\u00e9todo de marcas de tiempo en el que los datos actualizados por una transacci\u00f3n m\u00e1s reciente no pueden ser sobrescritos por una m\u00e1s antigua<\/h4>\n

\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0435\u0439 \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u043d\u0430\u0434 \u0434\u0430\u043d\u043d\u044b\u043c\u0438 \u0438\u043c\u0435\u044e\u0449\u0430\u044f \u043d\u0430\u0447\u0430\u043b\u043e \u0438 \u043a\u043e\u043d\u0435\u0446 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0447\u0442\u0435\u043d\u0438\u044f \u0438 \u0437\u0430\u043f\u0438\u0441\u0438. \u041e\u043a\u043e\u043d\u0447\u0430\u043d\u0438\u0435\u043c \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u043c\u043e\u0436\u0435\u0442 \u0431\u044b\u0442\u044c \u043b\u0438\u0431\u043e \u0441\u043e\u0445\u0440\u0430\u043d\u0435\u043d\u0438\u0435 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u0444\u0438\u043a\u0441\u0430\u0446\u0438\u044f, commit) \u043b\u0438\u0431\u043e \u043e\u0442\u043c\u0435\u043d\u0430 \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439 (\u043e\u0442\u043a\u0430\u0442, rollback). \u041f\u0440\u0438\u043c\u0435\u043d\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u043a \u0411\u0414 \u0442\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u0437\u0430\u043f\u0440\u043e\u0441\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0442\u0440\u0430\u043a\u0442\u0443\u044e\u0442\u0441\u044f \u043a\u0430\u043a \u0435\u0434\u0438\u043d\u044b\u0439 \u0437\u0430\u043f\u0440\u043e\u0441. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0434\u043e\u043b\u0436\u043d\u044b \u0443\u0434\u043e\u0432\u043b\u0435\u0442\u0432\u043e\u0440\u044f\u0442\u044c \u0441\u0432\u043e\u0439\u0441\u0442\u0432\u0430\u043c ACID \u0410\u0442\u043e\u043c\u0430\u0440\u043d\u043e\u0441\u0442\u044c. \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u043b\u0438\u0431\u043e \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0442\u0441\u044f \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-30878","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Transacciones y mecanismos de control | ProHoster","description":"Transacciones Una transacci\u00f3n es una secuencia de operaciones sobre datos que tiene un inicio y un final. Una transacci\u00f3n es la ejecuci\u00f3n secuencial de operaciones de lectura y escritura.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0438 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u044b \u0438\u0445 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f | ProHoster","og:description":"\u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0438 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u0435\u0439 \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u0442\u0441\u044f \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u043d\u0430\u0434 \u0434\u0430\u043d\u043d\u044b\u043c\u0438 \u0438\u043c\u0435\u044e\u0449\u0430\u044f \u043d\u0430\u0447\u0430\u043b\u043e \u0438 \u043a\u043e\u043d\u0435\u0446 \u0422\u0440\u0430\u043d\u0437\u0430\u043a\u0446\u0438\u044f \u044d\u0442\u043e \u043f\u043e\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0435 \u0432\u044b\u043f\u043e\u043b\u043d\u0435\u043d\u0438\u0435 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0447\u0442\u0435\u043d\u0438\u044f \u0438 \u0437\u0430\u043f\u0438\u0441\u0438.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/tranzaktsii-i-mehanizmy-ih-kontrolya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:37:56+00:00","article:modified_time":"2019-10-31T18:37:56+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"30878","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-22 15:31:13","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:27:38","updated":"2026-02-22 15:31:13","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/30878","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=30878"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/30878\/revisions"}],"predecessor-version":[{"id":162008,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/30878\/revisions\/162008"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=30878"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=30878"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=30878"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

\nLa transacci\u00f3n T<\/b> solicita modificar los datos Q<\/b>. Si TS(T)<\/b> < W-TS(Q)<\/b>, es decir, si la transacci\u00f3n intenta sobrescribir un valor m\u00e1s nuevo, la transacci\u00f3n T no se retrocede como en el m\u00e9todo de marcas de tiempo.
\n
Fuente: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"