в фибах есть свой таймер, отваливаемся по нему

hvlad писал(а) Mon, 11 March 2024 16:26

OIT "застревает" совершенно от другого.

От недофетченного курсора он обязан застревать при консистентности.

hvlad писал(а) Mon, 11 March 2024 16:26

И никак не связан с накоплением и\или сборкой мусора.

В любом случае мусора будет больше и снимок TIP будет разбухать.

МП

hvlad

pastor

наше все - автоотключение пользователя по таймауту.
доводов ЗА - миллион

ConnectionIdleTimeout в помощь

это который в API обозван isc_dpb_connect_timeout?  :evil:

Иди доку чти, evil

Для минимизации рисков нужно уметь их оценивать. Где твои оценки ? На чём они основаны ?

Пока что и вижу, что ты не понимаешь что такое OIT и на что он влияет.

Какие высоконагруженные объекты с таким уровнем знаний ?

а нету у вас больше нихрена в isc_dpb_ХХХ

pastor

в фибах есть свой таймер, отваливаемся по нему

ConnectionIdleTimeout не зависит от клиента.

hvlad писал(а) Mon, 11 March 2024 16:32

pastor

в фибах есть свой таймер, отваливаемся по нему

ConnectionIdleTimeout не зависит от клиента.

в 2.5 ?

МП

а нету у вас больше нихрена в isc_dpb_ХХХ

У тебя тоже обострение ?
Или бан в гугле не снят ?

Читай doc/README.session_idle_timeouts

hvlad писал(а) Mon, 11 March 2024 16:41

МП

а нету у вас больше нихрена в isc_dpb_ХХХ

У тебя тоже обострение ?
Или бан в гугле не снят ?

Читай doc/README.session_idle_timeouts

не надо делать мне красиво.
функции для аттачмента ты реализовал, а на DPB забил болт.

А почему оно должно быть в DPB ?
И где твоя (вежливая) просьба об этом ?
И чем тебе не подходит SET SESSION IDLE TIMEOUT, если уж на то пошло ?

sim_84

Параметр ReadConsistency не рулит транзакциями. Он переключает поведение для isc_tpb_reс_version и isc_tpb_noreс_version чтобы они превращались или нет в isc_tpb_read_consistency.

Другое дело, что дефолтное значение 1 для ReadConsistency спорно.

Спорить нужно было лет 8 назад, когда оно появилось в альфе\бете.
И, нет, ходить всю жизнь по лезвию - не есть причиной заставлять всех новичков делать так же.

sim_84

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

Какой вред ? Кто его измерил и может показать ?
Не в искуственном тесте.

Давай-ка ты сначала прочитаешь хотя бы релизноты от 4-ки, хотя бы разделы про ReadConsistency и изменения в сборке мусора.

Ну лично я никакого вреда не замечал. У меня есть недофетченные курсоры в гридах, которые висят по пол дня. Но ночером люди таки расходятся, так что и OST двигается вперёд.
Если кто-то на ночь приложение не выгружает, то соединение само отрубится по тайм-ауту простоя соединения (4 часа).

hvlad писал(а) Mon, 11 March 2024 16:45

Давай-ка ты сначала прочитаешь хотя бы релизноты от 4-ки, хотя бы разделы про ReadConsistency и изменения в сборке мусора.

Вот прямо оттуда:
Each new top-level statement creates its own database snapshot that sees the most recently committed data.

т.е. недофетченный курсор означает что этот "snapshot" будет жить пока не достигнут eof.
Больше там ничего не написано.

У меня вот 24x7 всё работает и отражает юзерам в реалтайме ситуацию. Такой таймаут вообще не вариант.

pastor писал(а) Mon, 11 March 2024 15:44

hvlad писал(а) Mon, 11 March 2024 16:32

pastor

в фибах есть свой таймер, отваливаемся по нему

ConnectionIdleTimeout не зависит от клиента.

в 2.5 ?

Тут вроде о 4-ке речь шла...
Пора бы уже бы и переезжать бы, как бы - на 5-ку

hvlad

А почему оно должно быть в DPB ?
И где твоя (вежливая) просьба об этом ?
И чем тебе не подходит SET SESSION IDLE TIMEOUT, если уж на то пошло ?

когда вы эти "безобразия" творили, я ещё только c 1.5 на 3.0 переползал

касаемо того, почему оно должно быть в DPB - дык, параметр коннекта, не иначе.
databases.conf конечно хорошо, действует до того как, но для всех коннектов этой базы, без разбора.
а Attachment::setIdleTimeout() действует на того кого надо, но таки после коннекта.
дополнительный раунд трип.
а если засандалить в DPB, то как говорят у нас в бухгалтерии - "я ничо не делала, а оно само!"

А как этот snapshot формируется ты читал? Начиная с 4.0 он очень дешёвый, и никакой приватной копии tip не делается.

Таки каждый юзер работают 24 часа в сутки? Ты хоть понял что это за тайм-аут? Это тайм-аут простоя соединения, то есть соединения в котором ничего не выполняется.

Что за сфера деятельности такая где юзеры по 24 часа работают?

Какая собственно разница? Версии записей всё равно должны удерживаться.

Соединение периодически из базы подгружает инфу и отражает на экране.

avp писал(а) Tue, 12 March 2024 13:06

Какая собственно разница? Версии записей всё равно должны удерживаться.

Не должны. Точнее должны, но не все, а только реально кому-то видимые. Именно поэтому RCRC и является умолчательным: у него нет недостатков по сравнению с RC. Параметр в конфиге - исключительно для багоюзеров.

avp

Соединение периодически из базы подгружает инфу и отражает на экране.

И откуда в этом случае недофетченные курсоры? То есть если это какое-то информационное табло, то не имеет смысла не до конца грузить курсор.

Давай всё таки разберёмся. У вас эти окна тупо открыты с недофетченными курсорами и ничего не делают или всё таки в них данные обновляются? Если данные постоянно обновляются 24/7, то курсоры как минимум надо переоткрывать, то есть никакого удержания версий не будет.

Если курсор недофетчен, то по идее все записи в базе должны удерживаться. Ибо заранее неизвестно какие записи затронет этот курсор.