Комментарии 9
Это ужасно :(
Читайте про двухфазную фиксацию транзакций и понимайте, что ваша схема не гарантирует нормальную работу.
Читайте про двухфазную фиксацию транзакций и понимайте, что ваша схема не гарантирует нормальную работу.
Вообще-то, «моя схема» и есть реализация протокола двухфазных транзакций. И почему, по-вашему, не гарантируется нормальная работа?
Во-первых, что по вашему понимается под двухфазной фиксацией? Этого я у вас не увидел
Во-вторых, поясните вот что:
Согласно вашей схеме, клон-А не может выполнить «физический» коммит, потому что не знает, успешен ли коммит на клон-Б. Клон Б тоже не может выполнить «физический» коммит, т.к. клон-А не отрапортовал о том, что все успешно (он ждет Б).
Как быть в этом случае?
Во-вторых, поясните вот что:
Согласно вашей схеме, клон-А не может выполнить «физический» коммит, потому что не знает, успешен ли коммит на клон-Б. Клон Б тоже не может выполнить «физический» коммит, т.к. клон-А не отрапортовал о том, что все успешно (он ждет Б).
Как быть в этом случае?
Двухфазная фиксация в моей схеме (см. диаграмму): каждый клон «рапортует» о том, что у него «всё в порядке» — утсанавливается статус «READY» который могут «прочитать» все клоны. После этого каждый клон ожидает статуса «READY» на всех других клонах. И после этого делает COMMIT БД. Это как-раз-таки и показано у меня на схеме. Возможно, вы говорите о «истинной двуфазной транзакции» (на уровне базы данных). Так у меня этого нет, я не спорю. Но это без проблем впишется в мою «схему» при необходимости.
Я упрошённо показал схему. На деле, конечно, всё дорабатывается, всех деталей я не отображал — схема получилась бы слишком сложной.
Я упрошённо показал схему. На деле, конечно, всё дорабатывается, всех деталей я не отображал — схема получилась бы слишком сложной.
Беда появляется там, где ее не ждали :)
Что будет, если
1. Все клоны выставят READY («все ОК»)
2. Затем первый клон закоммитит физически (все ведь ОК);
3. Второй клон зафэйлится на коммите
?
Ясно, что клоны 3 и далее успешно откатятся, но что делать с первым?
Что будет, если
1. Все клоны выставят READY («все ОК»)
2. Затем первый клон закоммитит физически (все ведь ОК);
3. Второй клон зафэйлится на коммите
?
Ясно, что клоны 3 и далее успешно откатятся, но что делать с первым?
Дествительно, такое может быть. У Вас есть какие-то соображения на этот счет?
Пока что у меня соображение, что в описанном случае ваша схема неприменима :) Не обижайтесь, просто задача, которую вы пытаетесь решить, весьма нетривиальна.
Подходящих решений описанной вами задачи клонирования изменений 2:
1. использовать репликацию данных «мастер»->«много детей», исключив распределенные транзакции;
2. использовать координатор настоящих распределенных транзакций, взаимодействующий с БД на низком уровне. Для MS SQL, с которым я работаю (из .net) — это MS Distributed Transactions Coordinator, встроенный в Windows. Для MySQL (Ваш случай) — понятия не имею об открытых аналогах. Ищите, возможно они есть.
Будет интересно, если вы найдете и напишете о нем.
Подходящих решений описанной вами задачи клонирования изменений 2:
1. использовать репликацию данных «мастер»->«много детей», исключив распределенные транзакции;
2. использовать координатор настоящих распределенных транзакций, взаимодействующий с БД на низком уровне. Для MS SQL, с которым я работаю (из .net) — это MS Distributed Transactions Coordinator, встроенный в Windows. Для MySQL (Ваш случай) — понятия не имею об открытых аналогах. Ищите, возможно они есть.
Будет интересно, если вы найдете и напишете о нем.
1. решение не подходит по техническим спецификациям. «мастера» быть не должно по требованиям
2. координатора нет, и взаимодействие с БД на низком уровне исключено, это тоже в технических требованиях. (базы данных потенциально могут находится на разных хостингах, доступ извне закрыт)
Вы, видимо, ошиблись немного веткой. Это решение исключительно для PHP. Не могу сказать (сокрее даже нет), что этот подход приемлем для .NET или Java. Предложенная мною схема приемлема. Работает. Если Вы не можете предложить решение лучшее, и не можете привести доводы, почему моя схема неприемлема, счетаю нашу дискуссию бессмысленной.
2. координатора нет, и взаимодействие с БД на низком уровне исключено, это тоже в технических требованиях. (базы данных потенциально могут находится на разных хостингах, доступ извне закрыт)
Вы, видимо, ошиблись немного веткой. Это решение исключительно для PHP. Не могу сказать (сокрее даже нет), что этот подход приемлем для .NET или Java. Предложенная мною схема приемлема. Работает. Если Вы не можете предложить решение лучшее, и не можете привести доводы, почему моя схема неприемлема, счетаю нашу дискуссию бессмысленной.
В последнем сценарии тоже работает? Наша дискуссия мне интересна по той причине, что, быть может, Вы мне поведаете, как заставить последний сценарий работать :)
Мне все равно, .net, java или что-то еще. Для mysql я нашел только решение на базе X/Open DTMC, было интересно, сравнивали ли Вы свое с чем нибудь или нет. То, что вы умеете изображать барьеры на диаграммах я уже понял, итересно обоснование решения.
Впрочем, если Вы считаете дисскусию закрытой, так тому и быть. В любом случае спасибо за информацию :)
Мне все равно, .net, java или что-то еще. Для mysql я нашел только решение на базе X/Open DTMC, было интересно, сравнивали ли Вы свое с чем нибудь или нет. То, что вы умеете изображать барьеры на диаграммах я уже понял, итересно обоснование решения.
Впрочем, если Вы считаете дисскусию закрытой, так тому и быть. В любом случае спасибо за информацию :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Синхронные клоны или простые распределенные транзакции (PHP)