Nikolay Ponomarenko wrote:
Почему бы не держать что-то вроде кеша препарированных запросов
соединения? Помнится Евгений Путилин что-то подобное делал для себя
- т.е. архитектурных препятствий нет?
В ФИБ есть какой-то внутренний кэш для QueryValue, но как он работает -
не знаю, одно время
Eugeney Putilin wrote:
Ты можеш подготовить запрос и использовать его неоднократно в многих
транзакциях.
Не очень понял, как это в FIB+ может выглядеть? Там же вроде с закрытием
транзакции все анпрепарится...
Konstantin R. Beliaev пишет:
Eugeney Putilin wrote:
Ты можеш подготовить запрос и использовать его неоднократно в многих
транзакциях.
Не очень понял, как это в FIB+ может выглядеть? Там же вроде с закрытием
транзакции все анпрепарится...
С чего ты так решил? :)
Удачи
Привет, [EMAIL PROTECTED]
bM С чего ты так решил? :)
bM Удачи
Ох, Вова, когда ж ты уже отполируешь все глюки
в этом своём JAM converter-э ?
--
With best regards, Alex Cherednichenko.
A K [EMAIL PROTECTED] wrote:
1) на каждый такой запрос открывать транзакцию, выполнять запрос,
закрывать
транзакцию
или
2) иметь одну общую транзакцию только для чтения, которая будет всегда
открыта.
Если транзакция READ COMMITTED, то (2) выгоднее с точки зрения сборки
мусора. Если же
A K [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
2) иметь одну общую транзакцию только для чтения, которая будет всегда
открыта.
подготовить на ней заранее все запросы и по мере обращения к ним подставлять
нужные параметры и выполнять эти запросы.
Вот так будет быстрее всего
Nikolay Ponomarenko [EMAIL PROTECTED] wrote in message news:[EMAIL
PROTECTED]
ручном вызове Unprepare, при разрушении компонента выполнившего
Prepare, при смене текста запроса.
Первый два случая понятны, но вот остальные - зачем?
остальные - это:
3) разрушении компонента выполнившего
7 matches
Mail list logo
