[SOLUCIONADO] ¿Como mantener la integridad de la bd y/o asegurarse de que se ejecuten todas las fn?

[Gloton]

Ejecuto por ejemplo 3 funciones.
Cada funcion inserta uno registro en una tabla, el otro inserta en otra tabla y el tercero tambien inserta en otra tabla.
Estas funciones php yo las ejecuto desde jquery utilizando ajax.

El problema es que cuando esta lenta se ejecuta solo 2 o una. Y lo mismo pasa cuando un usuario "dispara el evento" y este cierra la pagina antes de que termine de ejecutarse las 3 funciones.

Con lo cual quedan registros huerfanos.

Me gustaria un consejo o algun colega que me diga como lo hacen ustedes.

[xfxstudios]

si estas haciendo el envio por ajax deves notificarle al usuario que se estan ejecutando las acciones, con algun loader o algo asi y emitirle una respuesta satisfactoria cuando estas entan lista

[xerifandtomas]

Lo mejor, no ejecutar ninguna consulta asta que no tengas todos los datos a insertar. O utilizar un trigger si es posible.

Así evitarás que consultas dependientes no queden a merced de ajax o el usuario.

[Gloton]

Iniciado por xerifandtomas

Lo mejor, no ejecutar ninguna consulta asta que no tengas todos los datos a insertar. O utilizar un trigger si es posible.

Así evitarás que consultas dependientes no queden a merced de ajax o el usuario.

Es una propuesta muy buena muchas gracias, no lo dare por soluciona mientras tanto para ver si me dan otro buen consejo como el tuyo.

[dashtrash]

Para eso es para lo que existen las transacciones

[Gloton]

Iniciado por dashtrash

Para eso es para lo que existen las transacciones

Excelente concepto , no lo habia escuchado. Lo investigare, gracias dashtrash.

[xfxstudios]

Iniciado por Gloton

Excelente concepto , no lo habia escuchado. Lo investigare, gracias dashtrash.

Para complementar la info que te dió dashtrash, te dejo algo en español que encontré:

http://blog.elcodiguero.com/mysql/tr...-en-mysql.html

tampoco sabia de ellas y veo lo útiles que pueden ser, igual documentate con el manual de php para su implementación con mysqli. Saludos

[Gloton]

Iniciado por xfxstudios

Para complementar la info que te dió dashtrash, te dejo algo en español que encontré:

http://blog.elcodiguero.com/mysql/tr...-en-mysql.html

tampoco sabia de ellas y veo lo útiles que pueden ser, igual documentate con el manual de php para su implementación con mysqli. Saludos

Espectacular

Bueno... aca en la empresa usan Oracle 11g asi que espero que tambien se pueda utilizar las transacciones tambien.

[gnzsoloyo]

Iniciado por Gloton

Espectacular

Bueno... aca en la empresa usan Oracle 11g asi que espero que tambien se pueda utilizar las transacciones tambien.

Todos los DBMS son transaccionales. De lo contrario no funcionarían, ni tendrían uso comercial.
Aprender a dominar las transacciones y concurrencia... bueno, ese es otro cantar.

[xerifandtomas]

Lo de las transacciones esta muy bien, y aun que no es algo que tengo muy estudiado, pienso que no resolvería este caso concreto que plantea solo con transacciones.

Corrijan me si me equivoco.

Se lanzan 3 peticiones AJAX consecutivas, a 3 archivos diferentes. Por lo que si aplicamos transacciones, cada una de esas consulta puede completarse o no, pero el resto de consultas no saben ni tienen por qué saber si la consultas anteriores se han ejecutado, ya que al ser hilos independientes, serán también transacciones independientes, ni siquiera el que se boquee la tabla afectaria ya que cada una de las sentencias va dirigida a una tabla diferente.

Por lo que antes de aplicar las transacciones, insisto en mi planteamiento.

Primero obtén todos los datos necesarios para las diferentes consultas, luego ejecútalas todas seguidas con o sin transacciones.

Corrijanme si me equivoco.

[gnzsoloyo]

Las tres peticiones, en el caso mencionado, podrían estar en una misma transacción, si se usan conexiones persistentes, o bien incluso representar procesos que se integran en un mismo Sp de la base de datos.
En la empresa en que trabajo contamso con WS que administran la transaccionalidad, y de todos modos ejecutan múltiples Sp, todos dentro de la misma transacción. El commiteo de la misma es la que confirma las acciones de los multiples SP.
Todo depende del diseño construido...

[dashtrash]

Iniciado por xerifandtomas

Lo de las transacciones esta muy bien, y aun que no es algo que tengo muy estudiado, pienso que no resolvería este caso concreto que plantea solo con transacciones.

Corrijan me si me equivoco.

Se lanzan 3 peticiones AJAX consecutivas, a 3 archivos diferentes. Por lo que si aplicamos transacciones, cada una de esas consulta puede completarse o no, pero el resto de consultas no saben ni tienen por qué saber si la consultas anteriores se han ejecutado, ya que al ser hilos independientes, serán también transacciones independientes, ni siquiera el que se boquee la tabla afectaria ya que cada una de las sentencias va dirigida a una tabla diferente.

Por lo que antes de aplicar las transacciones, insisto en mi planteamiento.

Primero obtén todos los datos necesarios para las diferentes consultas, luego ejecútalas todas seguidas con o sin transacciones.

Corrijanme si me equivoco.

Son dos cosas distintas.
El OP hablaba de 3 funciones.
Tú hablas de 3 peticiones ajax distintas.

Si el problema es que , o se ejecutan todas las queries, o no se debería ejecutar ninguna, significa que desde el punto de vista de la aplicación, esa secuencia es "atómica":o existe, completa, o no existe.
Por lo tanto, que tengas que obtener todos los datos necesarios antes de realizar la operación, no es la solución.Es un requsito.
Ya tienes todos los datos necesarios.
Ahora supón que la primera query tarda mucho en ejecutarse, y el usuario cierra el navegador (y el php no lo controla).
O supón que en la segunda query, hay un bug.
O que se cae la BD antes de la tercera.
Es ahí donde las transacciones te solucionan el problema.

El supuesto de 3 request ajax independientes no puede suceder, ya que, en ese caso, tras cada request, se habria completado sólo parte del proceso de actualización de la BD.Y, entre las requests, la BD sería incoherente.Mucho peor, si el navegador se cerrase entre las requests.

[xerifandtomas]

A eso es a lo que me refiero dashtrash y la verdad me parece este un tema interesante.

Segun el planteamiento del problema inicial entiendo que recaba la información de forma parcial y tal cual la recibe la va insertando o actualizando en la bd de forma asíncrona mediante AJAX , por lo que crea inconsistencia en la bd, cuanto menos temporal.

Lo que me lleva a pensar esto es por esta parte donde dice:

El problema es que cuando esta lenta se ejecuta solo 2 o una. Y lo mismo pasa cuando un usuario "dispara el evento" y este cierra la pagina antes de que termine de ejecutarse las 3 funciones.

Ya que si dispara el evento y se ejecuta el php es indiferente de que el usuario cierre el navegador o no. La integridad de las tablas se puede romper por los puntos que has expuesto, pero no se debería romper por acción directa del usuario.

Por eso indicaba que antes de ejecutar las sentencias y/o las transacciones, lo mejor es tener todos los datos.

Es verdad que como indica gnzsoloyo, realizando conexiones persistentes se podría realizar, pero también entiendo que eso puede suponer un costo bastante alto y en muchos casos no es asumible.

[xfxstudios]

Si analizamos bien y con lo exageradamente poco que se sobre las transacciones, la colsulta original indica que se realizan tres funciones de inserción en la BD desde un ajax no tres peticiones desde ajax, en ese caso, seria algo como asi:

Código PHP:

$db->autocommit(false);
 
$a = $db->query("loquesea");
$b = $db->query("loquesea");
 
if($a !== false && $b !== false){
$db->query("COMMIT");
}else{
$db->query("ROLLBACK");
 
//redirecciono mostrando algun error o lo que sea
}
 

claro esto sería lo básico, imagino que hay mas por medio en el asunto

[xerifandtomas]

Pues investigando un poco veo que php provee métodos para trabajar con transacciones ( PDO, mysqli ) es más, recomiendan controlarlas haciendo llamadas a la API en lugar de hacerlo mediante SQL.

Tomando como base tu ejemplo y desde mi ignorancia en el tema, bien podría quedar asi:

Código PHP:

$db->autocommit(false);
 
$a = $db->query("loquesea");
$b = $db->query("loquesea");
 
if($a !== false && $b !== false){
$db->commit();
}else{
$db->rollback();
 
//redirecciono mostrando algun error o lo que sea
}
 

[gnzsoloyo]

Es una decisión de diseño. Dependerá de qué hay que hacer y en que contexto.
Usar la API puede ser buena idea en ciertos casos y un problema en otros, de acuerdo a la estabilidad del sistema o sus limitaciones, o incluso an la necesidad de ejecutar toda la tarea como algo integral en la base.

Sin saber como es el caso, No se puede recomendar uno u otro.

Vamos a suponer, como ejemplo, un escenario: Tienes tres operaciones que debe hacerse en una misma transacción, y tu aplicación tiene un timeout configurado en 120 segundos (una barbaridad, son dos minutos). Suponiendo que la duración de cada proceso a realizar incluyendo el overhead de red sea de 20 segundos, puedes enviarlos sucesivamente o en tres hilos sin problemas, e incluso puedes enviarlos a realizar todos a la base. El tiempo mínimo será de 20 segundos y el máximo será de 60.
Pero si uno de los procesos dura 60 segundos y los restantes 30 cada uno, no puedes mandarlos en forma sucesiva. Si o si tienen que ejecutarse en paralelo, o cae en error por causas ajenas al procesamiento. Esa ejecución en paralelo puedes hacerla en hilos de la base de datos, o bien en hilos de peticiones diferentes. La conveniencia de una u otra solución dependerá de qué realizan esos procesos, dado que enviarlos a hilos de la base puede evitar overhead de cada petición, que sería única. En ese contexto TAL VEZ una sola llamada a la base sea una buena idea.

Lo que quiero expresar es que no hay una sola y única consideración a tener en cuetna para determinar qué solución se debe aplicar. Depende del contexto.