Transaction Processing Utilizzo di PHP e MySQL

Question

Sto cercando di implementare commit in due fasi utilizzando PHP e MySQL, e in arrivo a breve.

Il blocco principale che ho trovato è che io sono in grado di memorizzare la risorsa di connessione MySQL in un posto dove posso trovare di nuovo per la seconda fase. E 'possibile serializzare un manico di database?

Ecco il caso che sto cercando di codice per:

1. utente invia i dati
2. Server avvia una transazione di MySQL ed esegue alcune query in base ai dati che ha ricevuto.
3. Server invia un file indietro per l'utente
4. Quando l'utente ha ricevuto correttamente il file, il server si impegna la sua transazione. In caso contrario, rotola indietro.

Questo sembra richiedere due HTTP Request / cicli di risposta, quindi ho bisogno di essere in grado di ri-connettersi allo stesso manico database nella seconda richiesta al fine di commettere la transazione. Sono stato fallendo a questa parte.

Qualsiasi consiglio è benvenuto, anche se è "questo non è possibile in PHP"

Answer 1

Date un'occhiata a Lixa Transaction Manager (http://lixa.sourceforge.net/) integra PHP e MySQL a partire dalla versione 0.9.0

Fornisce elaborazione delle transazioni distribuita e due phase commit caratteristica pure.

Saluti

Ch. F.

Answer 2

Dal momento che PHP è richiesta / risposta basata l'implementazione di una connessione permanente DB non è possbile, per quanto ne so.

Si potrebbe provare a ovviare a questa limitazione utilizzando una sorta di meccanismo di ticketing. sarebbero i tuoi passi:

1. utente invia i dati
2. Server avvia una transazione di MySQL ed esegue alcune query in base ai dati che ha ricevuto, l'assegnazione di un biglietto 'unico' per tale operazione.
3. Server invia un file e il biglietto di ritorno per l'utente
4. Quando l'utente ha ricevuto correttamente il file e inviato un'altra richiesta contenente quel biglietto, il server si impegna la sua transazione. In caso contrario, rotola indietro.
5. riferendosi al commento di Cassy: dopo un certo periodo di tempo TA non tutto commessi devono essere ripristinate al fine di evitare che il vostro db da beeing 'inondato' con le vecchie transazioni

HTH

Answer 3

di rispondere KB22 e rojoca, la ragione per cui ho bisogno di farlo in questo modo è che il 'file' a cui mi riferisco è in realtà un database SQLite che finisce come un archivio di dati su un dispositivo mobile.

La prima richiesta i messaggi del database SQLite aggiornato al server, che tenta di unire nei dati dalle tabelle SQLite; problemi sorgono quando il dispositivo mobile non riceve con successo un nuovo database SQLite (una che riflette i cambiamenti del dispositivo mobile e qualsiasi altro nuovo materiale dal web application), perché sarà quindi tentare di inviare lo stesso (vecchia) del database SQLite per la web una seconda volta, con conseguente voci duplicate nelle tabelle web per tutto ciò che è stato creato sul dispositivo mobile.

Quindi, il web ha bisogno di essere sicuri che il dispositivo ha il nuovo database prima di commettere i cambiamenti di unione. Dati i capricci delle reti, questo sembra possibile solo se il dispositivo può inviare un ACK esplicito dopo aver ricevuto il nuovo database SQLite. E questo è possibile solo se facciamo due richieste (1. Il database SQLite per unire, 2. l'ACK di ricezione del nuovo database SQLite sul dispositivo).

Un problema spinoso in effetti, ed è informazioni utili per scoprire che PHP non può manipolare database gestisce fino al livello necessario.

[anche io non penso di poter utilizzare una tabella di transazione perché ho bisogno di restituire i dati al dispositivo in base alle tabelle di database web 'reali'. Penso che mi piacerebbe correre in problemi con i campi di AUTO_INCREMENT se non ho usato le tabelle reali]

Grazie per tutti i vostri commenti.