|
ggvс таблицами как раз все сложней и хуже.
С таблицами я могу легко и привычно сделать практически все, что мне надо - в смысле перегона данных к себе в базу. Впрочем спорить тут не о чем - стоит задача и надо ее выполнить, схему получения данных определяю не я.
С MQ все проще - но почитать надо и представлять как все работает
Почитал, но, очевидно, до конца не понял.
Пока message не будет с ИХ сервера доставлено и сохранено на ВАШЕМ - оно не будет удалено на ИХНЕМ
Вот! И в описаниях всех так написано. Вот я только не могу ясно понять - что понимается под ИХ сервером: DB2, их менеджер очередей или, может быть, приложение, которое работает прослойкой между БД и менеджером?
никакого вам backup не надо для обеспечение такой схемы - вам гарантируется однократная доставка сообщений.
Про этоя читал. Однако слова в документации (о ИХ сервере и МОЕМ сервере) я воспринял таким образом, что сервер - это менеджер очереди сообщений. И как любая программа он должен эти сообщения хранить до тех пор пока у него их не заберут. Но тут я почитал немного документации и мне показалось, что сообщения на ИХ сервере удалятся только тогда, когда их получит программа-клиент через МОЙ сервер. Так? Для такой схемы обязательно ли нашим серверам быть в одном TCP сегменте и в одном кластере? Кстати - тут выяснилось, что никто, специально для нас, не создает очередей. А на самом деле - есть одна очередь к которой будет допущено некоторое количество клиентов. Я должен забрать с нее сообщения, которые еще не получал, но НЕ УДАЛЯТЬ их (лично мне в этой схеме непонятно, кто и когда, в таком случае, будет их удалять). Кстати вот с такой проблемой, видимо, придется столкнуться - если я забираю из таблицы, то, в случае порчи их на стороне приемника (ну мало ли - повредился файл базы физически), я мог развернуть последний бэкап и просто запустить процедуру обновления - она бы из таблицы источника забрала бы снова те данные, которые были утеряны. А как тут быть - непонятно, просить перепослать... так в режиме общей очереди тогда у других участников может продублироваться.
У вас может постоянно висеть обработчик, вызывающий GET для получения сообщений, а можно просто настроить тригер, который будет срабатывать по некоему условию, типа приход сообщения, или достижение глубины очереди определенного количетсва сообщений, ну и так далее.
Ну до этого мне еще разбираться и разбираться. Вот сейчас не могу найти - как мне в своем менеджере зарегистрировать очередь на удаленном сервере? Или как заставить получать свою очередь сообщения из ИХ очереди? Не нашел нигде, что бы спрашивало ай-пи очереди сообщений. Нашел в хелпе как сделать простейшую MQ сеть, но случай дан для одного сегмента сети TCP/IP с присоединением к дефолтному кластеру, после чего все-все находится самостоятельнои автоматически. Как быть если у меня есть адрес-порт-имя менеджера и имя очереди? Версия - 5.2 все же.
Но вспе равно - сначала доки, потом что-то хаять, типа как же оно все неправильно устроено :)
Если у Вас сложилось впечатление, что я что-то хаю, значит я недостаточно точно формулировал свои мысли. Мне очень интересно разобраться с новым моментом, думаю, что опыт этот полезный будет, просто для глубокого проникновения в суть вопроса нет времени и поэтому приходится вот просить помощи. Тем более, я думал, что в моем варианте реализация должна быть достаточно простой, что бы знающие люди с ходу просто и понятно объяснили.
|
