Чем грозят длинные транзакции в FireBird ?

← →
kudatsky (2010-10-18 10:22) [0]

Разрабатывается СУБД на FireBird+Delphi+FibPlus. Будут задействованы SavePoints, поэтому повидимому без длинных транзакций не обойтись. Не исключены ситуации, когда транзакция стартует утром, а подтверждается вечером. База будет иметь объём несколько ГБ и будут одновременно работать до сотни пользователей. Чем грозит такая ситуация в связи с использованием длинных транзакций ? Главное - будет ли система работать стабильно ?

← →
Sergey13 © (2010-10-18 10:24) [1]

> [0] kudatsky (18.10.10 10:22)
> Главное - будет ли система работать стабильно ?

ИМХО главное - будет ли она вообще работать?

← →
kudatsky (2010-10-18 10:30) [2]

Она в общем то уже работает. Вполне стабильно. При 4-х или 5-х пользователях (тестировщиках) и при объёме 50 МБ. Вопрос - что будет при 100 пользователях ?
Главное - скажутся ли открытые транзакции на стабильности работы ?

← →
Sergey13 © (2010-10-18 10:35) [3]

> [2] kudatsky (18.10.10 10:30)
> Вопрос - что будет при 100 пользователях ?

Насколько я помню курс марксистско-ленинской философии - критерием истины является практика. 8-)
Ты на чем предлагаешь нам гадать - на гуще кофейной или какой то другой приблуде?

← →
kudatsky (2010-10-18 10:40) [4]

Я и задавал вопрос практикам. Любителей погадать прошу не беспокоиться ;-)))

← →
Sergey13 © (2010-10-18 10:45) [5]

> [4] kudatsky (18.10.10 10:40)

А в чем практика то? "Несколько ГБ" и "100 пользователей" - это по твоему почва для предположений? Ну, тогда 50/50 - либо будет либо нет. 8-)

← →
Anatoly Podgoretsky © (2010-10-18 11:33) [6]

> kudatsky (18.10.2010 10:22:00) [0]

В общем случае грозит коллапсом.

← →
Медвежонок Пятачок © (2010-10-18 13:18) [7]

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

и ты еще сомневаешься?

← →
Игорь Шевченко © (2010-10-18 13:41) [8]

не будет

← →
Виталий Панасенко (2010-10-18 15:32) [9]

Да, если транзакция пишущая и
> Не исключены ситуации, когда транзакция стартует утром,
> а подтверждается вечером. База будет иметь объём несколько
> ГБ и будут одновременно работать до сотни пользователей.
>

то первая же попытка изменить данные ДРУГИМ пользователем приведет к ошибке...

← →
MsGuns © (2010-10-18 21:01) [10]

У автора, по-видимому, весьма смутное представление о том, что есть "транзакция"

← →
Правильный$Вася (2010-10-19 18:28) [11]

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

← →
kudatsky (2010-10-25 14:43) [12]

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

← →
Sergey13 © (2010-10-25 14:56) [13]

> [12] kudatsky (25.10.10 14:43)

А что вы этим всем пытаетесь достигнуть? Какова идея фикс сего предприятия? Если не секрет, что за предметная облать?

← →
kudatsky (2010-10-25 15:07) [14]

Это ГИС - географическая информационная система. Точнее - редактор схем электрических сетей. Редактируется поопорная схема линии электропередачи. Каждая опора ЛЭП ставится на карте (топографической основе) на своё родное место.

← →
Виталий Панасенко (2010-10-25 15:14) [15]

> Для этого в специальное поле каждой используемой строки
> ставится признак занятости. Если строка занята, то другие
> пользователи могут только видеть её состояние до начала
> транзакции.

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

← →
Sergey13 © (2010-10-25 15:16) [16]

> [14] kudatsky (25.10.10 15:07)

Ну и при чем тут транзакции на день?
Застолбил все нужные опоры за конкретным пользователем

> Для этого в специальное поле каждой используемой строки
> ставится признак занятости. Если строка занята, то другие
> пользователи могут только видеть её состояние
Точка.

а

> до начала транзакции.
зачем?

Если уж так важна целостность ВСЕХ опор сразу. Сделай копию заблокированных, отредактируй их, а потом шустренько замени оригиналы.

← →
kudatsky (2010-10-25 15:18) [17]

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

← →
kudatsky (2010-10-25 15:22) [18]

>Sergey13
Мысль неплохая. Но как при этом использовать точки сохранения ? Я хочу дать пользователю возможность отойти на пару шагов назад.

← →
Sergey13 © (2010-10-25 16:06) [19]

> [18] kudatsky (25.10.10 15:22)

Копии можно плодить. И убивать по мере надобности. Второе даже необходимо.

← →
Sergey13 © (2010-10-25 16:11) [20]

+
Только копии в данном случае будут называться версиями, среди которых могут быть рабочие (те которые "железно" в БД) и временные, над которыми работа идет. Последняя временная, после утверждения, становится последней рабочей.

← →
kudatsky (2010-10-25 16:20) [21]

Как то это всё сложно... Там ведь не одна таблица, а несколько.
Так что насчёт надёжности и возможных последствий вообще ?
Какие могут быть проблемы ? Может, пока не поздно, отказаться от SavePoints ?
Пока при нескольких пользователях всё вроде бы работает.

← →
Виталий Панасенко (2010-10-25 16:29) [22]

а если метку выставил, а прога/система "упала"?

← →
kudatsky (2010-10-25 16:36) [23]

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

← →
Sergey13 © (2010-10-25 16:39) [24]

> [21] kudatsky (25.10.10 16:20)
> Как то это всё сложно...
Никто и не обещал, что все просто.

>Там ведь не одна таблица, а несколько.
Ну и что? Конечное количество то надеюсь. 8-)

← →
Виталий Панасенко (2010-10-25 16:42) [25]

> Если сигнал
> сколько то раз не поступил, то занятые строки освобождаются.
>

А кто этим будет заниматься?

> [25] Виталий Панасенко (25.10.10 16:42)
> А кто этим будет заниматься?

Админ упавшего сервера. Все выходные путь сидит. 8-)

← →
kudatsky (2010-10-25 16:50) [27]

Примем человека на пол-ставки, пусть трудится ;-)))
Проще всего запустить циклический процесс. Раз в минуту проверить достаточно.

> [27] kudatsky (25.10.10 16:50)

Ну вот с 9-00 до 16-00 человек пахал в поте лица. И только он захотел завершить работу, у него (или не у него, а сеть, или не сеть, а сервак) заглючило. Проверили - не отвечает. И что, 7 часов работы псу под хвост?

ИМХО, побьют. 8-)

← →
kudatsky (2010-10-25 17:13) [29]

Насчёт человека - это шутка. Я же написал - запустить циклический процесс.
Запустить прогу, которая раз в минуту (или раз в секунду) будет всё это проверять

← →
Виталий Панасенко (2010-10-25 17:13) [30]

да и еще вопрос: если ТРАНЗАКЦИЯ НЕ ПОДТВЕРЖДЕНА, ТО НИКТО ЭТИ САМЫЕ МЕТКИ НЕ УВИДИТ! во веки веков... либо нужно два прохода: выставить метки, а затем уже редактировать данные.. либо как в фибах - холостой апдейт БЕЗ комита, заблокирует запись

← →
kudatsky (2010-10-25 17:17) [31]

>Виталий Панасенко
Так и делается. Сначала отдельная транзакция ставит метки и закрывается, а потом стартует редактирующая транзакция

← →
kudatsky (2010-10-25 17:26) [32]

Друзья, спасибо за беседу. Кое-что я из неё почерпнул.
У меня кончается рабочий день. Завтра утром я сюда загляну.

← →
Виталий Панасенко (2010-10-25 17:36) [33]

А можно вести типа версии. Т.е. каждое ПОДТВЕРЖДЕННОЕ редактирование порождает НОВУЮ версию(читай "запись") данных об объекте. Предыдущая становится типа не актуальной. Тогда для отката достаточно удалить(переместить, не суть) последнюю запись, предыдущая станет актуальной

← →
kudatsky (2010-10-26 09:38) [34]

>Виталий Панасенко
Можно. Но у меня к этому не лежит душа ;-)
И как насчёт SUBJ ?
Хотелось бы услышать квалифицированное мнение,
основанное на глубоком знании и собственном опыте.

> [34] kudatsky (26.10.10 09:38)

> Но у меня к этому не лежит душа ;-)

То, что тебе лень что-то делать - это конечно мощный аргумент, который перешибает любой довод против. 8-)
Во всех книгах/статьях по БД (это про "квалифицированное мнение") написано, что транзакции чем короче тем лучше. Нигде нет про их длительность "от меня и до вечера".
Твой подход напоминает старинный анекдот про испытание японской бензопилы в нашем лесхозе, где решили попробовать спилить бетонный столб.
Продолжай в том же духе и возможно появятся "глубокие знания" в этом вопросе, и уж точно появится "собственный опыт".

← →
Виталий Панасенко(дом) (2010-10-26 21:37) [36]

да, все мною прочитанные статьи, книги и т.д. в один голос говорят - "чем короче пишущая транзакция, тем лучше"... читающая.. да хоть до скончания времен(которое с 50% вероятностью из Нета наступит где-о через 3,5 млрд. лет с нынешним развитием науки)!

Чем грозят длинные транзакции в FireBird ? Найти похожие ветки