MySQL Transaction через многие Запросы PHP

Знайте, что ловля этих необработанных исключений может изменить требования к защите Вашего приложения. Ваше приложение может прекратить работать правильно под определенными контекстами (когда выполнено от сетевого ресурса, и т.д.). Обязательно протестируйте полностью.

7
задан Martin 21 November 2009 в 22:07
поделиться

5 ответов

you don't want to have long running transactions, because that'll limit concurrency. http://en.wikipedia.org/wiki/Command_pattern

7
ответ дан 6 December 2019 в 15:23
поделиться

The translation on the web for this type of processing is the use of session data or data stored in the page itself. Typically what is done is that after each web page is completed the data is stored in the session (or in the page itself) and at the point in which all of the pages have been completed (via data entry) and a "Process" (or "Save") button is hit, the data is converted into the database form and saved - even with the relational aspect of data like you mentioned. There are many ways to do this but I would say that most developers have an architecture similar to what I mentioned (using session data or state within the page) to satisfy what you are talking about.

You'll get much advice here on different architectures but I can say that the Zend Framework (http://framework.zend.com) and the use of Doctrine (http://www.doctrine-project.org/) make this fairy easy since Zend provides much of the MVC architecture and session management and Doctrine provides the basic CRUD (create, retrieve, update, delete) you are looking for - plus all of the other aspects (uniqueness, commit, rollback, etc). Keeping the connection open to mysql may cause timeouts and lack of available connections.

4
ответ дан 6 December 2019 в 15:23
поделиться

The solution is not to open the transaction during the GET phase. Do all aspects of the transaction—BEGIN TRANSACTION, processing, and COMMIT—all during the POST triggered by the "save" button.

1
ответ дан 6 December 2019 в 15:23
поделиться

Database transactions aren't really intended for this purpose - if you did use them, you'd probably run into other problems.

But also you can't use them as each page request uses its own connection (potentially) so cannot share a transaction with any others.

Keep the modifications to the invoice somewhere else while the user is editing them, then apply them when she hits save; you can do this final apply step in a transaction (albeit quite a short-lived one).

Long-lived transactions are usually bad.

2
ответ дан 6 December 2019 в 15:23
поделиться

Постоянные соединения могут вам помочь : http://php.net/manual/en/features.persistent-connections.php

Другой пример - при использовании транзакции, блок транзакции будет также перенести на следующий скрипт который использует это соединение, если скрипт исполнение заканчивается до транзакции блок делает.

Но я рекомендую вам найти другой подход к проблеме. Например: создать кеш-таблицу. Когда вам нужно «зафиксировать», перенесите записи из таблицы кэша в «настоящие» таблицы.

0
ответ дан 6 December 2019 в 15:23
поделиться
Другие вопросы по тегам:

Похожие вопросы: