место транзакций в архитектуре

[fixxxer]

Счетчики, да. И три статуса - no_transaction / pending / in_transaction. Pending заодно позволяет стартовать транзакцию только когда надо (с первым последующим запросом).
Еще чуток кода - и добавляется менеджер соединений, позволяющий эмулировать транзакции между разными субд. А если еще прикрутить XA (и метод vote() в соединения), получаются честные двухфазные коммиты.

На php таких реализаций не видел (кроме как у себя ), в python-мире существует весьма грамотный zodb transaction.

 

[Ragazzo]

fixxxer

Еще чуток кода - и добавляется менеджер соединений

а все лишь для того чтобы обернуть 2 запроса в транзакцию

 

[WMix]

а все лишь для того чтобы обернуть 2 запроса в транзакцию

update server_de.money set sum = sum - 10000000000 where customer = $from;
update server_ru.money set sum = sum + 10000000000 where customer = $to;
// Notice: Undefined variable $to...
// You have an error in your SQL syntax...

прикинь да..

 

[Redjik]

Счетчики, да. И три статуса - no_transaction / pending / in_transaction. Pending заодно позволяет стартовать транзакцию только когда надо (с первым последующим запросом).
Еще чуток кода - и добавляется менеджер соединений, позволяющий эмулировать транзакции между разными субд. А если еще прикрутить XA (и метод vote() в соединения), получаются честные двухфазные коммиты.

На php таких реализаций не видел (кроме как у себя ), в python-мире существует весьма грамотный zodb transaction.

Я сейчас на будущее думаю, как это все дело подружить с репликацией...
Менеджер соединений есть.

 

[С.]

прикинь да..

Где ты такое средневековье увидел?

insert into server.money set sum = 10000000000, from = $from, to = $to;

 

[WMix]

внимательней, сервера разные...

 

[С.]

Да хоть разные планеты. Неверную архитектуру нельзя лечить транзакциями.

 

[WMix]

С. это класический пример трансакции, описывающий основную проблему(открой любую книжку там будет подобный пример)! непонимаю почему ты такой поперечный!

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

fixxxerа все лишь для того чтобы обернуть 2 запроса в транзакцию

 

[С.]

А зачем ты прибел этот умозрительный бородатый пример из книжки? Чтобы продемонстрировать важность транзакций? Так никто в этой теме и не сомнвается этом.

 

[Ragazzo]

WMix
Если это разные сервера уже, а не БД, то я думаю имеет смысл делать синхронизацию, а не в коде просто "лапать" обращение к серверам ну это так, на заметку)

 

[fixxxer]

Ragazzo
если это разные сервера, то ничего, кроме two phase commit, не сработает по определению

 

[fixxxer]

Я сейчас на будущее думаю, как это все дело подружить с репликацией...
Менеджер соединений есть.

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

 

[grigori]

три статуса - no_transaction / pending / in_transaction. Pending заодно позволяет стартовать транзакцию только когда надо (с первым последующим запросом).

объясни пожалуйста в каком случае возникает состояние pending? транзакция на уровне базы или есть, или нет

Еще чуток кода - и добавляется менеджер соединений, позволяющий эмулировать транзакции между разными субд. А если еще прикрутить XA (и метод vote() в соединения), получаются честные двухфазные коммиты.

На php таких реализаций не видел (кроме как у себя )\

тут один серьезный вопрос: как ты реализовал фазу голосования на mysql?
протокол tfc подразумевает наличие у СУБД WAL и поддерджку "почти закоммиченных" данных, которой у MySQL нет.

если коммит в MySQL в одной из баз обломится из-за конфликта с другой транзакцией - что ты делаешь?
или ты подразумеваешь, что к базам не должно быть индивидуальных обращений со стороны?

 

[grigori]

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

про управление репликацией мы не думаем,
у нас как-раз менеджер соединений, он реализует интерфейс объекта соединения по паттерну компоновщик, смотрит на тип запроса (модификация или чтение), и решает по какому соединению отправить запрос
теперь в него надо добавить обработку вложенных транзакций

 

[Redjik]

когда же я научась ТАК изъясняться =((

 

[fixxxer]

протокол tfc подразумевает наличие у СУБД WAL и поддерджку "почти закоммиченных" данных, которой у MySQL нет.

Как это нет? Во-первых, log-bin это и есть WAL, во-вторых - XA.

в каком случае возникает состояние pending

Это такой выпердреж, откладывающий реальное исполнение BEGIN до первого реального запроса в транзакции - с ним можно не думать и стартовать транзакцию сильно раньше

у нас как-раз менеджер соединений, он реализует интерфейс объекта соединения по паттерну компоновщик, смотрит на тип запроса (модификация или чтение), и решает по какому соединению отправить запрос
теперь в него надо добавить обработку вложенных транзакций

не вижу проблем

 

[grigori]

fixxxer, спасибо