Синхронизация независимых баз данных (трансакция)

MiksIr · 29 Окт 2014

Я бы на CAS делал, без всяких демонов.

Т.е. логика такая. И -> З - дай измененные записи, по флагу в базе З "изменен".
И заносит данные в свою базу и далее И -> З говорит "пометь такие то ID синхронизированными", но кроме ID передает еще время изменения записи (которое пришло от З на первом шаге).
З сверяет пришедшее время и время в базе, если равно - сбрасывает "изменен", если не равно - просто ничего не делает - эта запись изменилась в процессе синхронизации и будет синхронизирована следующим этапом.

fixxxer · 29 Окт 2014

Тогда уж можно просто валить в соседнюю временную табличку, и по "псевдокоммиту" делать insert - select - on duplicate key update.

WMix · 29 Окт 2014

MiksIr написал(а):
Я бы на CAS делал, без всяких демонов.

Т.е. логика такая. И -> З - дай измененные записи, по флагу в базе З "изменен".
И заносит данные в свою базу и далее И -> З говорит "пометь такие то ID синхронизированными", но кроме ID передает еще время изменения записи (которое пришло от З на первом шаге).
З сверяет пришедшее время и время в базе, если равно - сбрасывает "изменен", если не равно - просто ничего не делает - эта запись изменилась в процессе синхронизации и будет синхронизирована следующим этапом.

так и сделал, а о XA думаю нужно делать 2х сторонний сервис и пусть координатор крутится в цикле

WMix · 29 Окт 2014

fixxxer написал(а):
Тогда уж можно просто валить в соседнюю временную табличку, и по "псевдокоммиту" делать insert - select - on duplicate key update.

да но тогда дубликатов таблиц будет много

grigori · 29 Окт 2014

в условии задано: общение должно происходить всегда в одну сторону по средствам soap,
заказчик не должен иметь возможности обновлять данные на момент синхронизации

т.е. есть клиент с одной частью данных, soap-сервер с другой частью, и они эти данные должны объединить. так отдай обработку серверу и оставь кесарю кесарево,

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

и атомарно, и пофиг что отвалились - соединиться еще раз и забрать обновления,
я так делал при оформлении покупки на удаленной "витрине" магазина, когда реально заказ оформлялся на rpc-сервере

если так не подходит - напиши чем

WMix · 30 Окт 2014

в условии задано: общение должно происходить всегда в одну сторону по средствам soap,

"какбы это останется", (да несколько перевернул задачу) в смысле координатор будет всегда один находиться в одном месте и он и только он будет отдавать активные soap запросы, а получать будет на свой сервис только состояния или данные, асинхронность иначе не решишь или я не соображу как. иначе soap функция будет крутится бесконечно ожидая ответа от Transaction Manager чтоб вернуть результат

предложи свой вариант!

grigori · 30 Окт 2014

WMix, сорри, но что-то я не понимаю связи твоего последнего сообщения со своим,
что именно остается?
координатор не нужен, асинхронность не нужна - простая съема клиент-сервер,
запросы не отдают, их или выполняют-отправляют, или обрабатывают-отвечают, и при чем тут координатор?

WMix · 31 Окт 2014

остается односторонняя связь "как бы",
webservice получается уже ассинхронно тк нужно отдать 2 запроса, которые могут выполниться только в одной сессии базы. те придется через канал пропускать до демона у которого всегда одна сессия.

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

WMix · 31 Окт 2014

а вообще я сам забыл, что в обратку не получается технически, на складе нет возможности открыть WS, там только исходящий ((
получается слишком запутано, самое первое решение всеже лучше. мне не нравиться что я 3 поля (дата обновления, дата синхронизации и дата блокировки) и 2 триггера (before insert/update) на каждую табличку копипастю с минимальными изменениями, но с другой стороны, "трансакция" эмулирована, и позволяет в несколько различных различных soap запросов свершиться

grigori · 31 Окт 2014

1. что значит фраза "односторонняя связь как бы" и к чему она относится?
2. веб-сервис не может быть синхронным или асинхронным - он удаленный, асинхронной может быть обработка ответа на клиенте, но это от тебя зависит,
3. какие 2 запроса куда и кому нужно отдавать?
4. у базы данных нет сессий - есть транзакции и соединения, причем, выполнение в одном соединении может иметь смысл только при выставлении переменных, в остальном - пофиг
4. почему 2 soap-запроса могут выполняться только в одной "сессии" (транзакции или коннекте) базы данных?
5. как выполнение 2х соап-запросов связано с демоном, и почему у демона может быть только одно соединение или транзакция?

прости, я не телепат, если ты "тихо сам с собой" - тогда сорри, не буду мешать

WMix · 31 Окт 2014

что значит фраза "как бы"? к чему она относится?

теперь уже не важно

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

5. как выполнение 2х соап-запросов в одной сессии связано с демоном, и почему у демона может быть только одно соединение или транзакция?

мы даем два отдельных запроса на вебсервис, а значит будет вероятно 2 различных соеденения с базой. В пределах одной трансакции так не получается.

2. веб-сервис не может быть синхронным асинхронным - он удаленный, асинхронной может быть обработка ответа на клиенте, но это от тебя зависит,

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

хотя можно сделать сервис дай состояние, которое либо NULL либо состояние. может и решение

grigori · 31 Окт 2014

мне кажется, ты на своей волне, и не очень хочешь обсуждать

WMix · 2 Ноя 2014

2. веб-сервис не может быть синхронным или асинхронным - он удаленный, асинхронной может быть обработка ответа на клиенте, но это от тебя зависит,

с этим согласился, но метод будет ждать ответа кружась в цикле

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

у пула может быть несколько, и выполнение в одном соединении == в одной сессии

3. какие 2 запроса куда и кому нужно отдавать?
4. почему 2 soap-запроса могут выполняться только в одной "сессии" (транзакции или коннекте) базы данных?
5. как выполнение 2х соап-запросов связано с демоном, и почему у демона может быть только одно соединение или транзакция?

координатор не нужен, асинхронность не нужна - простая съема клиент-сервер,
запросы не отдают, их или выполняют-отправляют, или обрабатывают-отвечают, и при чем тут координатор?

я попробывал нарисовать свое видение, как сократить не понимаю.
если только выкинуть вебсервис и общаться сразу через queue

AnrDaemon · 3 Ноя 2014

VPN вроде не отменяли.

WMix · 3 Ноя 2014

AnrDaemon написал(а):
VPN вроде не отменяли.

не каждый заказчик это позволит. а открыть простой web-service с 2мя методами get и set не такое и большое капиталовложение. а если уже заранее подготовить готовую программульку, то вообще проблем не будет. а выгода на лицо особено для маленьких магазинов, у которых готовая платформа по продаже, но склада своего нет.

grigori · 3 Ноя 2014

WMix, есть реальность, и она достаточно далека от твоих фантазий.
Никаких сессий у базы данных нет, и пуллов - тоже. Пулл баз данных есть на уровне приложения или прокси, но они тут не нужны. Никакой демон не сможет обеспечить постоянство соединения с базой.
Будет ли клиент ждать ответа от сервера в цикле, или отрубится, через 5 минут соединится опять и заберет результат - это вопрос алгоритма, а не принципа.

Я задачу с удаленными магазинами решил без XA, без очередей и без демонов, но если хочешь решить ее по-своему - решай. Обосновать ее сказочными сессиями, эльфами и пуллами невозможно, просто решай как хочешь.

флоппик · 3 Ноя 2014

grigori написал(а):
Никаких сессий у базы данных нет, и пуллов - тоже.

У мускула, ты хотел сказать.

WMix · 3 Ноя 2014

ха это ты подсказал, да по большому счету он тут не нужен, хотя если еще один виток сделать и разделить prepare и commit, будет дополнительное успокоение.

Никаких сессий у базы данных нет, и пуллов - тоже. Пулл баз данных есть на уровне приложения или прокси, но они тут не нужны.

http://de1.php.net/manual/en/mysqli.quickstart.connections.php Connection pooling

Никакой демон не сможет обеспечить постоянство соединения с базой.

мне на всю жизнь и не нужно, достаточно на полную сессию от begin до commit

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

grigori · 3 Ноя 2014

мне на всю жизнь и не нужно, достаточно на полную сессию от begin до commit

это до первого внезапного дисконнекта, которые в жизни случаются регулярно, maintenance или зависания сервера на чужом тяжелом запросе,
failover необходим, постоянное соединение с базой данных - фикция,
следствие 1: алгоритм надо строить с расчетом что соединение будет в любой момент разорвано и через некоторое время восстановлено,
следствие 2: раз все-равно переподключаться - лучше работать по событиям и состояниям,
то есть при отправке большого объема данных дешевле сразу написать отключение после отправки запроса и опрос состояния обработки, и не писать failover при сбое.
а при маленьком можно и повисеть, надо смотреть на объемы и время обработки

Connection pooling

pconnect-ы никакого отношения к твоему случаю не имеют,
они чаще вредны, и в PDO вообще не реализованы
почему они назвали пулом простое не-закрытие соединений для повторного использования - наверное, понтов ради

флоппик написал(а):
У мускула, ты хотел сказать.

речь явно не о постгресе и не о mysqlproxy

WMix · 3 Ноя 2014

следствие 1: алгоритм надо строить с расчетом что соединение будет в любой момент разорвано и через некоторое время восстановлено,

все правильно, зачем нам еще нужна трансакция, а темболее 2пц.

следствие 2: раз все-равно переподключаться - лучше работать по событиям и состояниям,
то есть при отправке большого объема данных дешевле сразу написать отключение после отправки запроса и опрос состояния обработки, и не писать failover при сбое.

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

pconnect-ы никакого отношения к твоему случаю не имеют,

это мое обьяснение зачем мне нужен демон, мол даже если использовать, оно не гарантирует.

Синхронизация независимых баз данных (трансакция)

miksir@home:~$

К.О.

герр M:)ller

герр M:)ller

( ͡° ͜ʖ ͡°)

герр M:)ller

( ͡° ͜ʖ ͡°)

герр M:)ller

герр M:)ller

( ͡° ͜ʖ ͡°)

герр M:)ller

( ͡° ͜ʖ ͡°)

герр M:)ller

Продвинутый новичок

герр M:)ller

( ͡° ͜ʖ ͡°)

promotor fidei

герр M:)ller

( ͡° ͜ʖ ͡°)

герр M:)ller