Firebird. Как сохранить промежуточное значение на сервере?

Bill2
Дата: 21.06.2012 15:24:37
Ситуация следующая.
Firebird 2.1.4. Всё можно делать только на стороне сервера.
При старте программы клиент запускает на сервере хранимую процедуру.
Внутри этой процедуры нужно сохранить промежуточное значение (уникальное для каждой сессии), для того, чтобы позже это значение использовала другая процедура.
Попробовал сохранить значение в global temporary table, но проблема в том, что первая процедура вызывается в транзакции Read, соответственно записать значение в таблицу не получается.
Есть ли какой-нибудь выход из этой ситуации?
Таблоид
Дата: 21.06.2012 15:27:46
Bill2,

RDB$SET_CONTEXT / RDB$GET_CONTEXT
Ivan_Pisarevsky
Дата: 21.06.2012 15:28:16
Может сначала формализовать проблему? А то "хочу писать в базу в ридонли транзакции" как минимум странная хотелка.
Таблоид
Дата: 21.06.2012 15:28:42
Bill2
Попробовал сохранить значение в global temporary table, но проблема в том, что первая процедура вызывается в транзакции Read, соответственно записать значение в таблицу не получается.
Хороший повод обратить взор в сторону 2.5.1: там в GTT можно писать даже в read-транзакции :-)
Bill2
Дата: 21.06.2012 15:30:55
Таблоид
Bill2,

RDB$SET_CONTEXT / RDB$GET_CONTEXT


Спасибо огромное!
Bill2
Дата: 21.06.2012 15:33:35
Таблоид
Хороший повод обратить взор в сторону 2.5.1: там в GTT можно писать даже в read-транзакции :-)

Не от меня зависит, а от разработчика клиентской части :)
Таблоид
Дата: 21.06.2012 15:41:52
Bill2
Таблоид
Хороший повод обратить взор в сторону 2.5.1: там в GTT можно писать даже в read-транзакции :-)

Не от меня зависит, а от разработчика клиентской части :)
а он что, еще и СЕРВЕРНУЮ часть под себя подмял ?
Bill2
Дата: 21.06.2012 17:08:23
Таблоид
а он что, еще и СЕРВЕРНУЮ часть под себя подмял ?

Ну, не то что бы подмял, просто не рекомендует :)

Еще раз благодарю, всё получилось.
чччД
Дата: 21.06.2012 17:34:12
Bill2
Таблоид
а он что, еще и СЕРВЕРНУЮ часть под себя подмял ?

Ну, не то что бы подмял, просто не рекомендует :)
...

Ну, "рекомендации" - это как бы не так категорично?
Таблоид
Дата: 21.06.2012 17:57:38
Bill2
Еще раз благодарю, всё получилось.
Сильно не обольщайтесь. Если к контекстным переменным будет много обращений, то начнёт играть роль то обстоятельство, что функции rdb$get/set_context() для ФБ до 2.5 включительно... *НЕ* ВСТРОЕННЫЕ, а такие же как и прочие UDF'ки. И затраты на многочисленные вызовы этих ф-ций, оказывается, совсем ненулевые!
Вот обсуждение на эту тему, с разъяснениями от одного из отцов-основателей.
Следующие слова dimitr'a про затраты на вызовы rdb$get_context() и rdb$set_context(), в ФБ до 2.5.х включительно, считаю настолько важными, что делаю копипаст сюда, дабы не забывались:
dimitr
<...> для движка это UDF! Черный ящик! Он не знает, что она делает внутри. При вызове любой UDF движок временно отпускает свою защиту. Такова стоимость вызова UDF.

посмотрел профиль - я таки угадал верно. На первом месте стоит работа с памятью, ибо это функция суть есть FREE_IT. На втором месте - копирование строковых значений туда-сюда. На третьем - мьютекс. На четвертом - сравнения строк (поиск предопределенных переменных).

кстати, можно проверить на 3.0. Там RDB$ переделаны как реальные встроенные функции (вместо псевдо-UDF) и из накладных расходов должно быть только копирование результата из временной переменной в дескриптор.