Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL / 16 сообщений из 16, страница 1 из 1
06.03.2019, 21:34
    #39783243
shalamyansky
shalamyansky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
Обращаюсь к другой базе на том же сервере из хранимой процедуры через

EXECUTE STATEMENT 'select ...' ON EXTERNAL 'db' WITH COMMON TRANSACTION

Хочется, чтобы эта common транзакция была READ_ONLY, да и другими её параметрами поиграть.

Как это можно сделать? Если не средствами языка, может, какими настройками?

Firebird 3.0 SuperServer
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
06.03.2019, 22:00
    #39783254
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
shalamyanskyКак это можно сделать?

Она потому и называется COMMON, что является частью транзакции в которой ты выполняешь
этот запрос. Соответственно её параметры - параметры транзакции, которые ты задаёшь.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
06.03.2019, 22:10
    #39783260
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
Dimitry Sibiryakov,

ну пока что и параметрами автономных транзакций даже для ON EXTERNAL нельзя играться
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 00:11
    #39783290
shalamyansky
shalamyansky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
Dimitry SibiryakovОна потому и называется COMMON, что является частью транзакции в которой ты выполняешь
этот запрос. Соответственно её параметры - параметры транзакции, которые ты задаёшь.

Логику вижу, но не понимаю. Да, фиксация или откат текущей и вызываемой тразакций будут сделаны совместно, поэтому их вместе можно даже назвать одной общей транзакцией на двух отдельных базах. Но почему бы не позволить вызываемой транзакции к другой базе быть, например read_only, не понимаю.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
07.03.2019, 01:37
    #39783296
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
shalamyanskyНо почему бы не позволить вызываемой транзакции к другой базе быть, например read_only, не
понимаю.

А зачем? Какой в этом практический смысл?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
25.09.2020, 08:07
    #40002402
bsv9
bsv9
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
Dimitry SibiryakovА зачем? Какой в этом практический смысл?
Например, имеем две базы: OLAP (хранилище) и OLTP (транзакционная). Хранимая процедура работает в базе OLAP, ей нужна пишущая транзакция и она работает очень долго. Кроме того, ей нужны данные из OLTP-базы. Это заставляет нас держать длинную пишущую транзакцию в OLTP-базе, для которой такие длинные транзакции категорически противопоказаны.

Поэтому возможность запускать read_only транзакцию в в EXECUTE STATEMENT ON EXTERNAL была бы тут очень кстати.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.09.2020, 08:49
    #40002409
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
bsv9,

забей. В 4.0 read only транзакция всё равно будет удерживать сборку мусора, пока курсор не закрыт или полностью не вычитан. Но она будет удерживать сборку мусора только для версий которые требуется ей, а не версий всех транзакций стартовавших после неё.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.09.2020, 10:41
    #40002444
YuRock
YuRock
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
Симонов Денис
забей. В 4.0 read only транзакция всё равно
Звучит как - останови все проекты и жди 4.0 :)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.09.2020, 10:43
    #40002445
hvlad
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
Симонов Денис
В 4.0 read only транзакция всё равно будет удерживать сборку мусора, пока курсор не закрыт или полностью не вычитан
Уточню - тут речь о read committed read consistency тр-циях.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.09.2020, 10:57
    #40002449
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
YuRock,

в EXECUTE STATEMENT в рамках 2.5 и 3.0 всё равно новых возможностей уже вносить не будут.
Так что просьба потенциально для 4.0, а там как я уже объяснил это имеет мало смысла.
Точнее может и имеет смысл, но хорошего обоснования её необходимости со стороны вопрошающих пока нет.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.09.2020, 12:15
    #40002483
hvlad
hvlad
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
Симонов Денис,

смысл есть, но придётся менять BLR, а это чревато проблемами при downgrade.
Ну и время на это, конечно, нужно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
25.09.2020, 12:44
    #40002495
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
bsv9Хранимая процедура работает в базе OLAP, ей нужна пишущая транзакция и она работает очень
долго. Кроме того, ей нужны данные из OLTP-базы. Это заставляет нас держать длинную
пишущую транзакцию в OLTP-базе, для которой такие длинные транзакции категорически
противопоказаны.

Во-первых, противопоказание не категорическое. Транзакция на десяток минут в нормальной
OLTP никого не убьёт. Во-вторых, в этой процедуре никто не заставляет её "держать".
Автономка будет в самый раз на то, чтобы вытянуть нужные данные во временные таблицы и
работать с ними хоть до позеленения. В-третьих, обычно в OLAP базы данные из OLTP совсем
другими методами. В-четвёртых, процедура, которая работает "очень долго" уже заставляет
нехорошо коситься на разработчика базы.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.10.2020, 08:19
    #40009111
Евгений Килин
Евгений Килин
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
YuRock
Звучит как - останови все проекты и жди 4.0 :)

Когда я регал хотелку звучало "Вроде не сильно сложно доработать, сделай заявку" :)
Полагаю в 4-ке тоже не сделают.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.10.2020, 19:10
    #40009340
shalamyansky
shalamyansky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
О, мою старую тему подняли, это хорошо. Поясню, откуда вопрос возник.

Есть "центральная" база OLTP и есть несколько дополнительных баз, которые являются по сути справочниками. Справочные базы основное время неизменны, но примерно раз в сутки для каждой из них (вразнобой) проходит большое обновление в одну или несколько длинных транзакций. Пополнение справочных баз проводится отдельным клиентом, центральная база в этом не участвует. Центральныя база обращается к справочным через execute statement on external , и только на чтение. Вообще-то и так неплохо получается, но вот какие есть связанные с этим соображения:

1. Если явно поставить транзакции execute statement on external флаг ReadOnly, это убережет от случайных попыток модификации справочников. Это, возможно, паранойя.

2. Если транзакция чтения проходит во время пополнения, и она вдруг окажется snapshot, ну мало ли, execute statement on external сидит внутри процедуры, а кто и когда вызовет эту процедуру, еще неизвестно, то в пополняемых справочниках начнет накапливаться мусор. Не смертельно, но все-таки, зачем копить лишнее.

Поэтому вызывать справочники хочется, явно задавая параметры транзакций для execute statement on external . Но не смертельно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.10.2020, 19:16
    #40009342
Dimitry Sibiryakov
Dimitry Sibiryakov
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
Ой-ё....

1. Select не может модифицировать таблицы. В особенности - случайно.
2. Мусор неспособен накапливаться в базах, который "в основном неизменны".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
16.10.2020, 19:28
    #40009344
Ivan_Pisarevsky
Ivan_Pisarevsky
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
shalamyansky
1. Если явно поставить транзакции execute statement on external флаг ReadOnly, это убережет от случайных попыток модификации справочников. Это, возможно, паранойя.
штатный механизм грантов чем не угодил?
shalamyansky
2. Если транзакция чтения проходит во время пополнения, и она вдруг окажется snapshot, ну мало ли, execute statement on external сидит внутри процедуры, а кто и когда вызовет эту процедуру, еще неизвестно, то в пополняемых справочниках начнет накапливаться мусор. Не смертельно, но все-таки, зачем копить лишнее.
Вот это уже паранойя.

Странные вводные, привели к странным выводам, хотя, да, хотелка по возможностям управления вполне годная.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL / 16 сообщений из 16, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 468ms
Закрыть
start [/forum/topic.php?fid=40&mobile=1&tid=1560225]:
 0ms
get settings:
 10ms
get forum list:
 15ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 131ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 52ms
get tp. blocked users:
 1ms
others: 239ms
total:  468ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]