Procesamiento de transacciones utilizando PHP y MySQL

Question

Estoy tratando de implementar la confirmación de dos fases usando PHP y MySQL, y me quedo corto.

El bloque principal que he encontrado es que no puedo almacenar el recurso de conexión MySQL en un lugar donde puedo encontrarlo nuevamente para la segunda fase. ¿Es posible serializar un mango de base de datos?

Aquí está el caso que estoy tratando de codificar:

1. El usuario envía datos
2. El servidor inicia una transacción MySQL y ejecuta algunas consultas en función de los datos que ha recibido.
3. El servidor envía un archivo al usuario
4. Cuando el usuario ha recibido con éxito el archivo, el servidor comete su transacción. De lo contrario, lo revertirá.

Esto parece requerir dos ciclos de solicitud/respuesta HTTP, por lo que necesito poder volver a conectarme al mismo manejo de la base de datos en la segunda solicitud para confirmar la transacción. He estado fallando en esta parte.

Cualquier consejo es bienvenido, incluso si es "esto no es posible en PHP"

Answer 1

Eche un vistazo a Lixa Transaction Manager (http://lixa.sourceforge.net/) Integra PHP y MySQL comenzando con la versión 0.9.0

Proporciona procesamiento de transacciones distribuidas y característica de confirmación de dos fases también.

Saludos

Ch. F.

Answer 2

Dado que PHP se solicita / respuesta basada en la implementación de una conexión DB persistente no es Possbile, AFAIK.

Podría tratar de trabajar en torno a esta limitación utilizando una especie de mecanismo de venta de boletos. Tus pasos serían:

1. El usuario envía datos
2. El servidor inicia una transacción MySQL y ejecuta algunas consultas en función de los datos que ha recibido, asignando un boleto 'único' a esa transacción.
3. El servidor envía un archivo y el boleto de regreso al usuario
4. Cuando el usuario ha recibido con éxito el archivo y ha enviado otra solicitud que contiene ese ticket, el servidor comete su transacción. De lo contrario, lo revertirá.
5. Consulte el comentario de Cassy: después de un cierto período de tiempo, todos los TA no cometidos deben volverse de regreso para evitar que su DB sea 'inundado' con transacciones antiguas

Hth

Answer 3

Para responder a KB22 y Rojoca, la razón por la que necesito hacerlo de esta manera es que el 'archivo' al que me refiero es en realidad una base de datos SQLite que termina como un almacén de datos en un dispositivo móvil.

La primera solicitud publica la base de datos SQLite actualizada al servidor, que intenta fusionar los datos de las tablas SQLite; Los problemas surgen cuando el dispositivo móvil no recibe con éxito una nueva base de datos SQLite (una que refleja los cambios del dispositivo móvil y cualquier otra cosa nueva de la aplicación web), ya que luego intentará enviar la misma base de datos SQLite (antigua) a la base de datos SQLite Web por segunda vez, lo que resulta en entradas duplicadas en las tablas web para cualquier cosa que se creara en el dispositivo móvil.

Por lo tanto, la web debe asegurarse de que el dispositivo tenga la nueva base de datos antes de cometer los cambios de fusión. Dados los caprichos de las redes, esto solo parece factible si el dispositivo puede enviar un ACK explícito después de recibir la nueva base de datos SQLite. Y esto solo es posible si hacemos dos solicitudes (1. la base de datos SQLite para fusionar; 2. El ACK de recepción de la nueva base de datos SQLite en el dispositivo).

De hecho, un problema espinoso, y es información útil para descubrir que PHP no puede manipular las manijas de la base de datos al nivel necesario.

Tampoco creo que pueda usar una tabla de transacciones porque necesito devolver datos al dispositivo en función de las tablas de base de datos web 'reales'. Creo que me encontraría con problemas con Auto_incement Fields si no usara las tablas reales

Gracias por todos sus comentarios.