MariaDB / Transacciones

Bienvenidos sean a este post, hoy hablaremos sobre las transacciones.

En posts anteriores estuvimos viendo y hablando sobre las transacciones, y como vimos en algunos ejemplos que disponemos de insttrtucciones para poder controlarlas, estas instrucciones nos permiten de forma explicita iniciar, ejecutar o volver atras las transacciones pero algunas operaciones son implicitas, tambien disponemos de poder crear niveles de aislamiento el cual determina cuales bloqueos son adquiridos y como son las lecturas consistentes, inclusive de una forma mas avanzada podemos declarar una transaccion como solo lectura lo cual nos posibilita ejecutar mas optimizaciones internas.

Comencemos hablando sobre el ciclo de vida de una transaccion, usualmente comienzan con un comando que vimos en varias ocasiones:

START TRANSACTION;

Y por lo general podemos terminarlo con:

COMMIT;

ROLLBACK;

El primero es finalizar la ejecucion de la transaccion y el segundo es para cancelar la transaccion y volver todo hacia atras, tambien podemos usar a BEGIN WORK que es un sinonimo de START TRANSACTION pero este no funcionara con programados almacenados debido al error de sintaxis que puede devolver con el uso de BEGIN y END, que son usados para crear bloques en el codigo, con esto aclarado veamos su sintaxis basica:

START TRANSACTION;
< Los comandos que sean necesarios >;
COMMIT;

Otro comando que podemos usar con START TRANSACTION es CHAIN, el cual permitira que se ejecute algun comando inmediatamente despues de haber llamado a COMMIT o ROLLBACK sin necesidad de tener que usar nuevamente a START TRANSACTION, algunos comandos no son transaccionales e implicitamente ejecutaran la transaccion actual, esta lista es muy larga pero podemos tomar como regla que las ejecuciones DML o DCL asi como las administrativas no son transaccionales, las unicas excepciones son las ejecuciones DML que envuelven a las tablas temporales, de manera predeterminada la variable del servidor autocommit tiene el valor ON, se puede modificar a nivel global o local pero si esta activada cada ejecucion se considera una transaccion al menos que se utilice START TRANSACTION, en cambio si esta desactivado se agrega un START TRANSACTION antes de cada ejecucion y luego del COMMIT o ROLLBACK.

Nuestro siguiente tema son los niveles de aislamiento, estos se componen de cuatro y podemos variar entre los mismos por medio de la siguiente opcion al inicio:

--trnasaction-level=<nivel>

O tambien lo podemos hacer por medio de la definicion de las variables de la siguiente forma:

MariaDB [base2]> SET @@tx_isolation = 'repeatable-read';

MariaDB [base2]> SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

Con estos dos metodos podemos establecer los niveles de aislamiento, por supuesto no podremos cambiarlo una vez que fue iniciado, cuando hablamos de los niveles de aislamiento este determina como los datos son accedidos por la transaccion actual que esta aislada de las otras conexiones, es decir que determina como las filas leidas son bloqueadas y si los snapshots son generados, aunque los niveles de aislamiento fuertes bloquea otras conexiones por un largo periodo de tiempo por lo que deben ser usados solo si son necesarios, con esto comentado pasemos a ver los niveles de aislamiento que disponemos:

• READ UNCOMMITTED, este nivel crea un snapshot separado por cada comando de lectura que es ejecutado en la transaccion, este snapshot podria consistir de los datos de una transaccion que no ha sido subida todavia y es posible que esta data no exista en la tabla.
• READ COMMITTED, este es similar al anterior pero a diferencia de este nunca utiliza valores que no han sido subidos, tanto UPDATE como DELETE o los bloqueos de lectura nunca utilizan los «gap locks» y esto puede terminar en la insercion de filas fantasmas
• REPEATABLE READ, es el nivel de aislamiento predeterminado, todas las lecturas en la transaccion usan el mismo snapshot, este nos garantiza mayor consistencia que el anterior, las ejecuciones de UPDATE, DELETE o los bloqueos de lectura y los bloqueos de ingreso seran usados en los indices UNIQUE y los otros indices de bloqueos de espacio o bloqueos de proxima clave se utilizaran para bloquear inserciones en el rango de valores escaneados
• SERIALIZABLE, podemos considerarlo como el nivel visto anteriormente donde todos los SELECT no bloqueables son convertidos automaticamente a LOCK IN SHARE MODE, si solo usamos SELECT bloqueables no habra diferencia entre este y el nivel anterior, otra situacion donde son identicos es cuando autocommit esta activado y esto es debido a que los bloqueos no son adquiridos si la transaccion actual finalizara con el query actual

Por ultimo en MariaDB 10.0 introduce los Modos de acceso de transacciones, existen dos tipos:

• READ WRITE, es para transacciones que podrian modificar los datos actuales
• READ ONLY, es para transacciones que solo leen datos

En READ ONLY como excepcion pueden modificar datos en tablas temporales pero al querer modificar un dato nos devolvera un error, esta puede ser especificada por medio de SET TRANSACTION:

MariaDB [base2]> SET TRANSACTION READ ONLY;

Y a su vez podemos usarlo cuando establecemos el nivel de aislamiento:

MariaDB [base2]> SET TRANSACTION ISOLATION LEVEL REPEATABLE READ, READ ONLY;

Si el autocommit esta activado MariaDB siempre sabe el modo de acceso exacto de una transaccion, en cambio si esta desactivado (o la transaccion comienza con START TRANSACTION) el modo de acceso es READ WRITE, pero si el motor sabe que es READ ONLY nos permite ejecutar algunas optimizaciones que mejoran la concurrencia.

En resumen, hoy hemos visto transacciones, que son, una descripcion de las mismas, como es su ciclo de vida, los niveles de aislamiento y por ultimo modos de acceso, espero les haya sido de utilidad sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.