|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
Обращаюсь к другой базе на том же сервере из хранимой процедуры через EXECUTE STATEMENT 'select ...' ON EXTERNAL 'db' WITH COMMON TRANSACTION Хочется, чтобы эта common транзакция была READ_ONLY, да и другими её параметрами поиграть. Как это можно сделать? Если не средствами языка, может, какими настройками? Firebird 3.0 SuperServer ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2019, 21:34 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
shalamyanskyКак это можно сделать? Она потому и называется COMMON, что является частью транзакции в которой ты выполняешь этот запрос. Соответственно её параметры - параметры транзакции, которые ты задаёшь. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2019, 22:00 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, ну пока что и параметрами автономных транзакций даже для ON EXTERNAL нельзя играться ... |
|||
:
Нравится:
Не нравится:
|
|||
06.03.2019, 22:10 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovОна потому и называется COMMON, что является частью транзакции в которой ты выполняешь этот запрос. Соответственно её параметры - параметры транзакции, которые ты задаёшь. Логику вижу, но не понимаю. Да, фиксация или откат текущей и вызываемой тразакций будут сделаны совместно, поэтому их вместе можно даже назвать одной общей транзакцией на двух отдельных базах. Но почему бы не позволить вызываемой транзакции к другой базе быть, например read_only, не понимаю. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2019, 00:11 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
shalamyanskyНо почему бы не позволить вызываемой транзакции к другой базе быть, например read_only, не понимаю. А зачем? Какой в этом практический смысл? Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
07.03.2019, 01:37 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovА зачем? Какой в этом практический смысл? Например, имеем две базы: OLAP (хранилище) и OLTP (транзакционная). Хранимая процедура работает в базе OLAP, ей нужна пишущая транзакция и она работает очень долго. Кроме того, ей нужны данные из OLTP-базы. Это заставляет нас держать длинную пишущую транзакцию в OLTP-базе, для которой такие длинные транзакции категорически противопоказаны. Поэтому возможность запускать read_only транзакцию в в EXECUTE STATEMENT ON EXTERNAL была бы тут очень кстати. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 08:07 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
bsv9, забей. В 4.0 read only транзакция всё равно будет удерживать сборку мусора, пока курсор не закрыт или полностью не вычитан. Но она будет удерживать сборку мусора только для версий которые требуется ей, а не версий всех транзакций стартовавших после неё. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 08:49 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
Симонов Денис забей. В 4.0 read only транзакция всё равно ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 10:41 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
Симонов Денис В 4.0 read only транзакция всё равно будет удерживать сборку мусора, пока курсор не закрыт или полностью не вычитан ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 10:43 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
YuRock, в EXECUTE STATEMENT в рамках 2.5 и 3.0 всё равно новых возможностей уже вносить не будут. Так что просьба потенциально для 4.0, а там как я уже объяснил это имеет мало смысла. Точнее может и имеет смысл, но хорошего обоснования её необходимости со стороны вопрошающих пока нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 10:57 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
Симонов Денис, смысл есть, но придётся менять BLR, а это чревато проблемами при downgrade. Ну и время на это, конечно, нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 12:15 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
bsv9Хранимая процедура работает в базе OLAP, ей нужна пишущая транзакция и она работает очень долго. Кроме того, ей нужны данные из OLTP-базы. Это заставляет нас держать длинную пишущую транзакцию в OLTP-базе, для которой такие длинные транзакции категорически противопоказаны. Во-первых, противопоказание не категорическое. Транзакция на десяток минут в нормальной OLTP никого не убьёт. Во-вторых, в этой процедуре никто не заставляет её "держать". Автономка будет в самый раз на то, чтобы вытянуть нужные данные во временные таблицы и работать с ними хоть до позеленения. В-третьих, обычно в OLAP базы данные из OLTP совсем другими методами. В-четвёртых, процедура, которая работает "очень долго" уже заставляет нехорошо коситься на разработчика базы. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2020, 12:44 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
YuRock Звучит как - останови все проекты и жди 4.0 :) Когда я регал хотелку звучало "Вроде не сильно сложно доработать, сделай заявку" :) Полагаю в 4-ке тоже не сделают. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 08:19 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
О, мою старую тему подняли, это хорошо. Поясню, откуда вопрос возник. Есть "центральная" база OLTP и есть несколько дополнительных баз, которые являются по сути справочниками. Справочные базы основное время неизменны, но примерно раз в сутки для каждой из них (вразнобой) проходит большое обновление в одну или несколько длинных транзакций. Пополнение справочных баз проводится отдельным клиентом, центральная база в этом не участвует. Центральныя база обращается к справочным через execute statement on external , и только на чтение. Вообще-то и так неплохо получается, но вот какие есть связанные с этим соображения: 1. Если явно поставить транзакции execute statement on external флаг ReadOnly, это убережет от случайных попыток модификации справочников. Это, возможно, паранойя. 2. Если транзакция чтения проходит во время пополнения, и она вдруг окажется snapshot, ну мало ли, execute statement on external сидит внутри процедуры, а кто и когда вызовет эту процедуру, еще неизвестно, то в пополняемых справочниках начнет накапливаться мусор. Не смертельно, но все-таки, зачем копить лишнее. Поэтому вызывать справочники хочется, явно задавая параметры транзакций для execute statement on external . Но не смертельно. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 19:10 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
Ой-ё.... 1. Select не может модифицировать таблицы. В особенности - случайно. 2. Мусор неспособен накапливаться в базах, который "в основном неизменны". Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 19:16 |
|
Управление транзакциями в EXECUTE STATEMENT ON EXTERNAL
|
|||
---|---|---|---|
#18+
shalamyansky 1. Если явно поставить транзакции execute statement on external флаг ReadOnly, это убережет от случайных попыток модификации справочников. Это, возможно, паранойя. shalamyansky 2. Если транзакция чтения проходит во время пополнения, и она вдруг окажется snapshot, ну мало ли, execute statement on external сидит внутри процедуры, а кто и когда вызовет эту процедуру, еще неизвестно, то в пополняемых справочниках начнет накапливаться мусор. Не смертельно, но все-таки, зачем копить лишнее. Странные вводные, привели к странным выводам, хотя, да, хотелка по возможностям управления вполне годная. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2020, 19:28 |
|
|
start [/forum/topic.php?fid=40&fpage=11&tid=1560225]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
72ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
others: | 12ms |
total: | 186ms |
0 / 0 |