Nikolay KulikovМожно посмотреть в сторону WebSphere MQ. Для informix есть MQ datablade. В хранимой процедуре или тригере кидаем в очередь сообщений данные. На другой стороне MQ получает данные и запускает по приходу сообщения процесс который вставляет данные в MySQL. Я бы для этого DB2 использовал так как там есть уже написанный агент который запускает по приходу сообщения хранимую процедуру в качества параметра которой передается сообщение или значения из сообщения.

+ Быстро и гарантированно данные будут попадать на сервер который стоит рядом с Web
-WebSphere MQ стоит денег

А если внешний процесс сделает роллбэк?
А сообщение уже ушло?

Ilya Kulagin Вэб сервер у провайдера, БД у нас. Не хочется логин к базе размещать у провайдера. Да и данные вэб серверу нужны далеко не все. Разместить информикс у провайдера вряд ли получится.

Тут, как понимаете, вариантов немного. Или, всё-таки, вебсервер имеет коннект (ну, пусть не к базе, а, например, к самонаписанному на, например, перле, "серверу приложений"), который по переданным ему в tcp-соединении с вебсервера параметрам делает тот или иной execute procedure (только упаси боже, не select - а то дыры замаетесь латать) в информиксе и возвращает данные обратно вебсерверу.

Или на 20 таблиц Вы вешаете 20*3 триггеров, которые по каждому изменению/вставке/удалению, например, запускают какой-либо system(), написанный, например, на том же перле, который эти данные вынимает из базы, складывает во временный буфер и запускает фиговину, которая данные из этого буфера будет пихать в мыскль (ни в коем случае не сам пихает - а то по малейшему таймауту соединения будет полная фигня с исходными транзакциями).

Обе схемы у меня работали. В случае триггеров, сами понимаете, объём всех тех race conditions, которые надо предусмотреть, больше в разы. Поэтому когда таблиц стало 2 вместо 1, я счёл за благо пойти по дороге номер 1.

аналогично, system из триггера пихнул изменения, но клиентская программа сделала откат тразакции.
Так делать нельзя

Ilya Kulagin cpr
аналогично, system из триггера пихнул изменения, но клиентская программа сделала откат тразакции.


В смысле - нельзя сделать триггер, который запустится до commit. Ну, нельзя. И что здесь неправильного?


почему нельзя? можно

триггер foreach row
сработает как раз до коммита.

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

Nikolay KulikovЭ не друг CPR.

Не понял, вы меня ни с кем не путаете?


Nikolay KulikovЧто в DB2 что в Informix MQ Datablade если ты работаешь с MQ у тебя будет 2 фазный commit. В случае с репликаций Транзакции которые в логе не завершились commit тоже не передадутся как сообщения.

Нифига не понял, а причем тут репликация?

Nikolay KulikovИзвини за фамильярность.


без проблем

Nikolay Kulikov
Репликация имелась в виду DB2-aя через MQ. Она когда обрабатывает лог она проверят транзакция завершилась Commit или нет. Соответсвенно если не завершилась то сообщения не отправляются.
драйвер для php.

Тогда это несколько не в тему, поскольку обсуждается ситуация, когда нет возможности гетерогенной транзакции. Если есть соответствующий Informix Gateaway manager, то вообще больше ничего не нужно - обращайся к внешней таблице, как к внешней БД Informix и все получится.

Nikolay Kulikov
p.s. по мне так проще было ER наладить и отказаться от MySQL, у Informix неплохой драйвер для php.

На самом деле лучший вариант брать напрямую из Informix, как предлагал камрад Журавлев Денис. Не понимаю чего здесь бояться, т.к. каким способом не свяжи, но машины должны быть как то соединены между собой, не дискетой же они будут файлы таскать.

Журавлев Денис cpr
На самом деле лучший вариант брать напрямую из Informix, как предлагал камрад Журавлев Денис. Не понимаю чего здесь бояться, т.к. каким способом не свяжи, но машины должны быть как то соединены между собой, не дискетой же они будут файлы таскать.Видимо ТЗ у них (или религия) -- ни одного листен порта снаружи.

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