Хотелось бы уточнить кто чем пользуется:

1 открыли Тр1 и она долго что то делает в базе в таблице Т2 забирая значение 2 из поля Fx таблицы Т1(id=1)=Fx(2)
2 открылась Тр2 и изменили значение 2 на 3 получили Т1(id=1)=Fx(3)
3 commit Тр2

и тут только тип транзакции Тр1 даст нам увидеть изменения в таблице Т1, я прав?

Чем воспользоваться чтобы не зависеть от типа транзакции что бы изменения были видны всегда?

Кроме генератора в голову ничего не приходит

Симонов ДенисЕвгений Болтик,

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

Сейчас я конкретней не куда вопросы задал.

Основной вопрос.

Чем воспользоваться чтобы не зависеть от типа транзакции что бы изменения были видны всегда?

Вижу пока 2 варианта генератор и timestamp

PS. Не важно для чего. Это снова начнется бессмысленное лабудение ;)

ExterisНезакоммиченные данные в другой транзакции вы не увидите.

По тексту я сделал коммит у Тр2 ;)

А вот от типа транзакции Тр1 будет зависеть увидит она эти изменения или нет. Гуру я прав?

Симонов ДенисНе надо хотеть ерунды. Хочешь видеть изменения в транзакции Tp1 при любом уровне изоляции рестартуй её. Других способов нет.

Не ну вот это злобно. Я задал вопросы. На которые надо ответить да/нет или будет так.

Ivan_PisarevskyЕвгений БолтикВижу пока 2 варианта генератор и timestampтаймштамп каким боком?

Евгений БолтикPS. Не важно для чего. Это снова начнется бессмысленное лабудение ;)Поменьше агрессии, ладно? Итак достаточно много постов на грани фола. Спасибо.

'now' тоже от транзакции не зависит
А там смайлик. Что это не злобное заявление.

Ivan_PisarevskyЕвгений БолтикПо тексту я сделал коммит у Тр2 ;)разницу между снапшот и ридкоммитед понимаешь?

В роди бы да студя по второму абзацу на который ты ответил. Но ты меня этим вопросом ввел в ступор.

Столько лет работаю проблем не наблюдал, а тут сомнения в знаниях.

Вроде ридкоммит должен увидеть закомиченные данные в Тр2. Иль я заблуждался?

Беседа приятная но долгая получилась;) Я виноват.
Всем спасибо. Слава богу что знал переосмысливать не надо.
Некоторые уложились в один пост подтвердив мои вопросы.
По вопросам поста было понятно, что вроде как знаю.
Прошу извинить, знаю много, но привык подвергать свои знания сомнениям. Т.к. знать и помнить все невозможно.

Теперь можно и о задаче поговорить.
Написана репликация полностью рабочая. За основу взято ВРЕМЯ.

Я задумался об одном узком месте (ВРЕМЯ) которое меня подводило как то, но на 4 компах эта проблема была решена простой синхронизацией времени. Я не могу объяснить почему и как я иногда знаю, что это будет "так". Но я смотрел на все это и понял блин будут проблемы из за долго играющих запросов(слава богу пока таких нет) которые меняют реплицируемые данные.

На клиенте запустили запрос он будет работать 30 сек. Идут изменения.
прошло 10 секунд началась репликация(черновое чтение я считаю тут недопустимым, отсюда все понятно становится вам) продолжительность обмена 10 сек.
Надеюсь не надо объяснять что обмен по времени не совсем хорошая идея, но этот вариант мне оказался тоже нужен :) для других целей.

1.склоняюсь ввести одно понятие версия.
Достоинством версии она не вверх не вниз не скакнет как время.
Но тут я снова вижу подвох. Наши долгоиграющие запросы.
Если даже долгоиграющий запрос увидит смену версии и будет метить записи то часть будет версии 5 а част 6. А т.к. при обмене будет прописано что забрали 5 вервии то эта часть из долгоиграющего запроса не попадет никуда.
Вот и рождается мысль 2 генератора в триггеры на базу на транзакции повесить. Но что то тоже не дает покоя(чет думаю не подойдет тоже)
Как отловить эту часть данных?

2.Есть еще одна мысль делать по принципу удаления при изменении или добавлении писать имя таблицы и ИД и потом забирать. Это самый простой способ, но затратный по числу записей. Особенно в основной базе которая будет данные раздавать дальше. Для такой раздачи приходится содержать таблицу подтверждений (в ней будет записей=кол-во баз помножено на кол-во записей целевых).
2.1Можно конечно поступить хитро при обмене просто в эти записи версию обмена впихнуть, а потом загрузить тогда таблица подтверждений снова не нужна будет.

Ivan_PisarevskyИспользуй везде снапшот и будет тебе счастье.

При обмене естественно снапшет использую с самого начала.

1.время имеет недостаток нужна строгая синхронизация. А вдруг время "слетело", сделали обмен, потом заметили. То есть тогда нужна защита от дурака. Кроме версий ничего не вижу лучше.
2.если просто версию добавить но тогда мы потеряем не часть данных, а полностью из той транзакции которая работала в ходе обмена.

и что то мне подсказывает дорога одна через отдельную таблицу в которую писать измененные таблицы и записи. А при обмене метить эти записи той версией которой забираем по факту

Гаджимурадов РустамЕвгений Болтик> Я задумался об одном узком месте (ВРЕМЯ) которое
Евгений Болтик> меня подводило как то, но на 4 компах эта проблема
Евгений Болтик> была решена простой синхронизацией времени.

Чтобы его не приходилось синхронизировать,
нужно чтобы время было одно - серверное. Нет?


Да. Если опираемся на "ВРЕМЯ" то время должно быть серверное. На удаленных серверах желательно синхронизироваться с этим главным сервером. В течении года проблем не наблюдал. Все работает как часы.

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

Массу вещей уже переписал начинаю тестирование и доводку.