DBExpress и больщое кол-во транзакций

← →
Vital (2004-10-28 18:12) [0]

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

← →
Johnmen © (2004-10-28 18:14) [1]

А не надо её держать. Надо её по быстрому закрывать и стартовать другую...

← →
Vital (2004-10-28 18:25) [2]

Да, а какже быть если хочется поброузить по данным, а вытякивать на клиента все сразу накладно?

← →
Johnmen © (2004-10-28 18:31) [3]

Как обычно, две тр-ции, пишущая и читающая...

← →
Vital (2004-10-28 18:36) [4]

А как в DBEspress создать ReadOnly Transaction ?(для чтения)

← →
Vital (2004-10-28 18:42) [5]

Все равно одна будет висеть.

← →
Zacho © (2004-10-28 19:46) [6]

Просто любопытно: какой еще "журнал транзакций" в FB ? Нет там ничего подобного. Или это "заморочки" DBExpress ?

← →
Vital (2004-10-28 20:51) [7]

Заморочки в том что, если приложение не закрывает Connection и начинает активно изменять базу (множество комитов), то это приводит к тормозу на сервере. Спасает только реконект.
Два компонента Conection тоже не спасают. В Fib и Ibx c таким не сталкивался.

← →
jack128 © (2004-10-28 21:30) [8]

Vital (28.10.04 20:51) [7]
Ну так нафиг на DBEspress перешел? ;-)

> Vital (28.10.04 20:51) [7] [Новое
>сообщение][Ответить]
> Заморочки в том что, если приложение не закрывает
> Connection и начинает активно изменять базу (множество
> комитов), то это приводит к тормозу на сервере.
> Спасает только реконект.

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

← →
Vital (2004-10-29 12:15) [10]

(GSTAT)
Database header page information:
Flags 0
Checksum 12345
Generation 2308
Page size 4096
ODS version 10.1
Oldest transaction 1795
Oldest active 2050
Oldest snapshot 2048
Next transaction 2300
Bumped transaction 1
Sequence number 0
Next attachment ID 7
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Oct 28, 2004 19:50:31
Attributes force write

После того как получается разница в несколько тыс между
Oldest transaction и Next transaction - тормоз.

Приходится отрубить и врубить конекшн перед пакетными операциями.
Может есть другой выход?

Компоненты доступа здесь не причём.
А по поводу твоей проблемы - читай http://www.ibase.ru/devinfo/oitoat.htm и т.д.

DBExpress и больщое кол-во транзакций Найти похожие ветки