Кто пользуе вот эту связку?
У меня есть подозрение что тут не всё работает правильно.
Эти компоненты принудительно при каждом открытии select запроса в TSQLQuery стартуют транзакцию и держат её открытой вплоть до закрытия запроса.
Это правильно, если сервер FireBird. И это не правильно для Postgre (как я понимаю, это будет ошибкой и для MSSQL/Sybase).
У кого есть мнение на эту тему? Постить в багрекер ошибку?
SQLdb компоненты и PostgreSQL
Модератор: Модераторы
Насколько я знаю SQLTransaction делает коммит только явно, то есть транзакция длится , пока пользователь ее не закроет. Не вижу ничего плохого.
-
alexs
- долгожитель
- Сообщения: 4066
- Зарегистрирован: 15.05.2005 23:17:07
- Откуда: г.Ставрополь
- Контактная информация:
Плохо то, что некоторые операции на клиентской части подразумевают - что список с данными может быть открыть долго. И всё это время будет висеть начатая транзакция. А это уже черевато тем, что могут возникнуть блокировки. Я с этим уже столкнулся.
Сама логика работы с транзакциями в пострегесе подразумеват, что атомарные запросы на выборки данных не надо оборачить в явную транзакцию.
Явная транзакция нужна только для того случая, когда надо гарантировано получать и изменять одни и теже данные.
PS
В ZEOS-е кстати всё работает правильно, но переходить на него в том проекте мне не хочется...
Сама логика работы с транзакциями в пострегесе подразумеват, что атомарные запросы на выборки данных не надо оборачить в явную транзакцию.
Явная транзакция нужна только для того случая, когда надо гарантировано получать и изменять одни и теже данные.
PS
В ZEOS-е кстати всё работает правильно, но переходить на него в том проекте мне не хочется...
Я просто делал на событие AfrerPost SQLTransaction.CommitRetraining
Может режим есть как в zeos
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
Знакомый трабл. А еще хуже что в Постгресе нет режима COMMITRETAINING. Требуйте от разрабов фишек SQLQuery типа как в MSE :
1) FAKE_TRANACTION - без стартового запуска тразакции
2) раздельные транзакции на чтение и запись
1) FAKE_TRANACTION - без стартового запуска тразакции
2) раздельные транзакции на чтение и запись
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
Насколько я понял Potstgre - в нём только одна транзакция на соединение бывает.
По протоколу, поодерживаются вложенные, включая именованные с сэйвпойнтами. Но Мартин как-то ухитрился наладить параллеьные типа независимые.
ct.COMMITRETAINING - в нём не нужен, т.к. есть не явный запуск транзакции на время sele
Еще как нужен - иначе, на уровне LIBPQ - автореконнект после каждого соммитта - ессно с потерей букмарков во всех датасетах, и т.п. Мартин опять-таки выкрутился через эмуляцию ретэйнинга ( с сохранением позиций ВСЕХ датасетов задейсованныхв транзакции - включая мастер-детали - то есть работу проделал большую), а чуть позже через параллельные транзакции (минус - нужно явно освежать чтение после коммитов) . Сам работаю в 90% случае с Постгресом, но есть-таки у него неприятные ограничения.
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
котекст открытых DataSet-ов не теряется.
На самом деле - чего им терятсься? Данные то сфетчены...
Не удивлюсь, если дефолтный Постгрес так решает проблемы рефреша косвенно (черед БД-таблицы) зависимых датасетов - просто инвалидурует ВСЕ датасеты. ОгнеПтица, по словам Мартина - умеет это делать без переконнекта. Каким только образом - не сканит же запросы для сличения списков таблиц...
Добавлено спустя 4 минуты 5 секунд:
Кстати, очень удобный билд - постоянная транзакция на чтение, и кротовременно срабатывающая- на запись. Перечитывание - в коде - в около-коммитном событии. Сам перешел на этот режим для всех типов серверов - удобно в плане надежности и минимизации траффика.
-
alexs
- долгожитель
- Сообщения: 4066
- Зарегистрирован: 15.05.2005 23:17:07
- Откуда: г.Ставрополь
- Контактная информация:
debi12345
Ты описываешь технолгию работы FireBird/Interbase - я сам на нём много чего делаю.
Сейчас работаю с постгре - там всёж реализация немного другая. По первому времени тоже хотел делать 2 транзакции...
Ты описываешь технолгию работы FireBird/Interbase - я сам на нём много чего делаю.
Сейчас работаю с постгре - там всёж реализация немного другая. По первому времени тоже хотел делать 2 транзакции...
-
alexs
- долгожитель
- Сообщения: 4066
- Зарегистрирован: 15.05.2005 23:17:07
- Откуда: г.Ставрополь
- Контактная информация:
А зачем? Все основные выборки идут в режиме неявного старта и завершения. Для select-запросов самое то. Транзакции не висят лишние на сервере. Нет блокировок.
А редактирование критичных областей уже обртываю в явную транзакцию. И этот код стараюсь делать коротким. В нём нет никакого ожидания от пользователя. Т.о. тоже на сервере не остаются висящие транзакции...
А редактирование критичных областей уже обртываю в явную транзакцию. И этот код стараюсь делать коротким. В нём нет никакого ожидания от пользователя. Т.о. тоже на сервере не остаются висящие транзакции...
-
debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
Плохо то, что некоторые операции на клиентской части подразумевают - что список с данными может быть открыть долго. И всё это время будет висеть начатая транзакция. А это уже черевато тем, что могут возникнуть блокировки. Я с этим уже столкнулся.
В принципе, досточно отключить отrрытие транзакции при стратовом SELECT-е - то есть расширить функционал TSQLTRANSCTION через новую опцию "FAKE TRANSACTION" для читающих транзакций (здсь подразумеваются две паралельные транзакции - посоянно открытая читающая и сеансовая пищущая ), которая запретит выхов SQL-команд BEGIN & COMMIT для TSQLTRANSCTION при загрузке прогаммы и COMMIT[RETAINING].
ПС:
Скажу еще за SQLITE3 версий до кажется "3.4" (у которых не было вложенных транзакций и поэтому любой сбой мог вынести всю дневную работу) - этот режим оказался настоящим спасением
