crear transaccion para asegurar proceso

[catpaw]

hola!!

Veran, tengo un proceso el cual usa 2 tablas "de paso" es decir, el usuario le da al boton y el programa, hace mas o menos lo siguiente:

1- select * from tabla1 //para extraer datos
2- delete tabla2 //resetear tabla
3- procesamiento y calculo de datos extraidos y generacion de nuevos datos
4- insercion de datos extraidos y generados en tabla2
5- presentacion de datos y de formulario con un boton que al presionarlo hace:

6- delete tabla3
7- select * a tabla2 where condicion1
8- proceso de datos extraidos y generacion de datos nuevos
9- insercion de datos tabla3
10- select * a tabla2 where condicion2
11- proceso de datos extraidos y generacion de datos nuevos
12- insercion de datos tabla3
13- select * tabla3 INTO OUTFILE a un txt
14- presentacion de datos y boton de descarga del txt

al final se genera un txt con los datos procesados y calculados de la tabla3

Se debe evitar que si un usuario a empezado el proceso, otro NO pueda usar las tablas ya que se cruzarian los datos y podrian obtener errores en el archivo de salida.

la idea seria "bloquear" las 2 tablas al inicio del proceso y desbloquerlas una vez que se haya generado el txt

he estado leyendo sobre innodb (el motor de mis tablas), sobre su tipos de bloqueo a nivel linea (shared S, exclusive X) y tabla (intention shared IS, intention exclusive IX) [si estoy mal corrijanme porfas]

el caso es que quisiera aplicar eso, seria un IX sobre las 2 tablas mientras se procesa la info.

Entiendo que debo crear una transaccion, mas o menos de la siguiente manera:

>BEGIN;
>QUERIES (selects, inserts, updates, ect -> todo mi proceso)
>COMMIT;

pero haber,

aqui en que momento declaro el IX y como?
y si tengo mi proceso en dos archivos php, es decir del paso 1 al 5 esta en pagina1.php y del 6 al 14 en pagina2.php, esto en que afecta la transaccion, en la parte de queries?
y puede haber la posibilidad de que el usuario no accione el boton del paso 5, que es el que hace que pase al paso 6 (un submit a pagina2.php) como podria "expirar" la transaccion despues de un tiempo considerable en que no se ha pasado del paso 5 al 6 (rollback)

agradezco sus comentarios

[gnzsoloyo]

Usa tablas de tipo TEMPORARY, en tiempo de ejecución.

Código MySQL:

CREATE TEMPORARY TABLE nombretabla (campos);
 

Las tablas temporary existen durante una sesión, y sólo pertenecen a ella; cuando la sesión se cierra, desaparecen solas.
Como además pertenecen a la sesión, sólo son visibles para esa única sesión de usuario, puedes usar los mismos nombres en dos sesiones sin que jamás se produzca conflicto.
Incluso más: Dos sesiones diferentes, con el mismo username y password, pueden crear tablas TEMPORARY del mismo nombre, y aún así no ser visibles entre ambas sesiones.
Creo que con eso alcanzará.

[catpaw]

Wow

hola gnzsoloyo, suena padrisimo lo que me comentas, justo lo que necesito, de ya pongo manos a la obra y les comento.

Buscare info sobre el tema, me imagino que se tratan de igual forma que una tabla normal, verdad?

Gracias

[gnzsoloyo]

Basicamente si. Es mejor trabajarlas en stored procedures, para evitar problemas de pérdidas de conexión, pero esencialmente son iguales, incluyendo la creación de indices (tambien son temproales), claves primarias y tipos de dato.
De hecho, se pueden crear con el famoso:

Código MySQL:

CREATE TEMPORARY TABLE tabla
AS SELECT a, b, c, 
FROM tabla_loquesea;
 

Si la quieres como copia de otra real:

Código MySQL:

CREATE TEMPORARY TABLE tabla
LIKE tabla_loquesea;
 

Y para mayor seguridad de errores yo suelo poner:

Código MySQL:

CREATE TEMPORARY TABLE IF NOT EXISTS tabla
...
 

[catpaw]

ok, en lo que he leido me preocupa un poco lo siguiente que encontre:

http://dev.mysql.com/doc/refman/5.0/...-problems.html

No puede referirse a una tabla TEMPORARY más de una vez en la misma consulta

Resulta que dentro de mi proceso hago como 3 consultas con UNION a la misma tabla, entonces esa consulta, si entiendo bien, no funcionara

Y luego esto que comentas:

Es mejor trabajarlas en stored procedures, para evitar problemas de pérdidas de conexión

me preocupa aun mas :/ porque no tengo experiencia con procedimientos almacenados y no podría permitir que hubiera un fallo de conexion en el proceso

[gnzsoloyo]

En realidad te estás ahogando anticipadamente, porque si bien ese tipo de tablas tiene algunas restricciones, nada impide que generes dinámicamente copias de esa misma tabla para saltear el problema.
Todo es cuestión de ingenio.
En referencia a los SP, te recomiendo que los uses para este caso, porque el 90% del proceso que describes se puede hacer en un sólo SP (he hecho algunos mucho más complejos). Y es posible que la experiencia te sirva más adelante.
Ahora bien, sería muy interesante saber a qué cálculos y procesamientos te refieres con estos puntos:

...
3- procesamiento y calculo de datos extraidos y generacion de nuevos datos
...

8- proceso de datos extraidos y generacion de datos nuevos
...
11- proceso de datos extraidos y generacion de datos nuevos
...

Porque podría llegar a ser que se puedan hacer por las mismas consultas, sin necesidad de procesamientos externos a las mismas. Claro que para estar seguro necesitaríamos más información. Con lo descripto allí no alcanza para darte un mejor consejo.
Pero es muy probable que se pueda hacer.

Lo único que no se puede hacer en un SP es el INTO OUTFILE, porque eso es una restricción a los SP.

[catpaw]

Si bueno, he seguido leyendo y me voy preocupando mas jaja, tal vez si tienes razón me estoy predisponiendo pero ya no estoy tan segura que usar tablas tamporales sea la mejor opcion ya que lei que las tablas duran mientras dure la conexion, mientras se ejecuta el script y se borran, la forma en que no se borren al terminar la ejecucion del script es usando conexiones permantes, las cuales se introdujeron en php 5.3 y la version del servidor en el que trabajo usa 5.1.

Lo que me refiero al procesar, calcular y generar datos, es mas que nada tomar resultados de consultas y mediante condicionales, crear variables con nuevos valores, por ejemplo, recupero un campo de importe y si cumple o no la condicion dada, se pueden: crear nuevas variables, cambiar valores recueperados en la consulta, dejar en blanco valores,

$variable2 = $row['cuenta_detalle'];

if($row['importe']>0){
$variable = "Algun texto";
$variable2 = "nueva cuenta detalle";
}

algo asi, pues hay ciertas condiciones, que deciden si asignar nuevos valores o conservar los existentes y en dados casos determinar nuevos.

En fin, si tengo, como ya habia explicado, 2 paginas en las que se realizan el proceso, no se si permanecera la conexion al cambiar de un script (pagina1.php) a otro (pagina2.php)

y lo principal del proceso es la generacion del txt con los datos cuadrados en el proceso.

gracias

[catpaw]

Opte por las transacciones, arme un ejemplo sencillo de una transaccion con la estructura que se asemeja a la del script final:

Código MySQL:

>SET AUTOCOMMIT=0;
>BEGIN;
>TRUNCATE TABLE uno;
>LOAD DATA LOCAL INFILE 'prueba.txt' INTO TABLE uno FIELDS TERMINATED BY '|';
>TRUNCATE TABLE dos;
>SELECT * FROM uno FOR UPDATE;
//en este punto mediante php hago un ciclo recorriendo registro por registro, $i es una variable incrementable
>INSERT INTO dos (clave, calle, colonia) VALUES ('$i', '$i', '$i');
//termina el ciclo
>SELECT * INTO OUTFILE 'C:/wamp/www/transaccion/prueba2.txt' FIELDS TERMINATED BY '' LINES TERMINATED BY '\\n' FROM dos FOR UPDATE
despues tengo una condicion si se ejecuto la instruccion anterior hace commit
>COMMIT;
si no un rollback
>ROLLBACK;
 

ahora el prueba1.txt contiene:

Código:

1|dexter|
2|ronaldo|
3|lucrecia|
4|rusky|
5|jordana|

y prueba2.txt resulta:

Código:

1          1                        1
2          2                        2
3          3                        3
4          4                        4  
5          5                        5

lo cual es correcto

pues bien por lo que lei y de acuerdo a mis necesidades uso SELECT FOR UPDATE, que opinan?

la idea es que una vez que la tabla uno este llena y se pidan los datos de la misma, nadie pueda ni leer y ni escribir en ella, despues al insertar en la tabla2 y hacer el select que introduce los valores de la misma al txt tambien nadie puede ni leer ni escribir en ella.