Processamento de transações usando PHP e MySQL

Question

Estou tentando implementar o comprometimento bifásico usando o PHP e o MySQL e ficando aquém.

O bloco principal que encontrei é que não consigo armazenar o recurso de conexão MySQL em um local onde posso encontrá -lo novamente para a segunda fase. É possível serializar em serializar um identificador de banco de dados?

Aqui está o caso em que estou tentando codificar:

1. O usuário envia dados
2. O servidor inicia uma transação MySQL e executa algumas consultas com base nos dados que recebeu.
3. O servidor envia um arquivo de volta ao usuário
4. Quando o usuário recebeu o arquivo com sucesso, o servidor comete sua transação. Caso contrário, ele rola de volta.

Isso parece exigir dois ciclos de solicitação/resposta HTTP, por isso preciso poder reconectar-se com o mesmo identificador de banco de dados na segunda solicitação para cometer a transação. Eu tenho falhado nesta parte.

Qualquer conselho é bem -vindo, mesmo que "isso não seja possível no PHP"

Answer 1

Dê uma olhada no LIXA Transaction Manager (http://lixa.sourceforge.net/) integra o PHP e o MySQL começando com a versão 0.9.0

Ele fornece processamento de transações distribuído e recurso de comprometimento de duas fases também.

Cumprimentos

CH. F.

Answer 2

Como o PHP é baseado em solicitação / resposta, a implementação de uma conexão persistente de banco de dados não é possível, a AFAIK.

Você pode tentar contornar essa limitação usando uma espécie de mecanismo de emissão de bilhetes. Seus passos seriam:

1. O usuário envia dados
2. O servidor inicia uma transação MySQL e executa algumas consultas com base nos dados que recebeu, atribuindo um ticket 'exclusivo' a essa transação.
3. O servidor envia um arquivo e o bilhete de volta ao usuário
4. Quando o usuário recebeu com sucesso o arquivo e enviou outra solicitação contendo esse ticket, o servidor comete sua transação. Caso contrário, ele rola de volta.
5. Referindo -se ao comentário de Cassy: Após um certo período de tempo, todos os TAs não cometidos devem ser revertidos para impedir que seu banco de dados seja 'inundado' com transações antigas

Hth

Answer 3

Para responder KB22 e Rojoca, a razão pela qual preciso fazer dessa maneira é que o 'arquivo' a que estou me referindo é na verdade um banco de dados SQLite que acaba como um armazenamento de dados em um dispositivo móvel.

A primeira solicitação publica o banco de dados SQLite atualizado no servidor, que tenta mesclar dados das tabelas SQLite; Os problemas surgem quando o dispositivo móvel não recebe com sucesso um novo banco de dados SQLite (que reflete as alterações do dispositivo móvel e qualquer outra coisa nova do aplicativo da Web), porque tentará enviar o mesmo banco de dados (antigo) sqlite para o Web pela segunda vez, resultando em entradas duplicadas nas tabelas da Web para qualquer coisa criada no dispositivo móvel.

Portanto, a Web precisa ter certeza de que o dispositivo possui o novo banco de dados antes de comprometer as alterações de mesclagem. Dados os caprichos das redes, isso só parece viável se o dispositivo puder enviar um ACK explícito após o recebimento do novo banco de dados SQLite. E isso só é possível se fizermos duas solicitações (1. O banco de dados SQLite se fundirá; 2. o ACK do recebimento do novo banco de dados SQLite no dispositivo).

Um problema espinhoso, de fato, e é uma informação útil descobrir que o PHP não pode manipular o banco de dados lida com o nível necessário.

Também acho que não posso usar uma tabela de transações porque preciso retornar dados ao dispositivo com base nas tabelas de banco de dados 'reais' da Web. Acho que teria encontrado problemas com os campos de auto_increntle se eu não usasse as mesas reais

Obrigado por todos os seus comentários.