Можно ли выполнить SQL-операторы в новом LUW'е, не зацепив уже существующий?

LAT

Здравствуйте.

Возникла следующая проблема. Есть [скажем так] фреймворчик. Появилась необходимость производить в нем гарантированное логирование, не влияя на основную работу. Т.е. во множестве мест уже существующего приложения реализовать следующую логику:

Code:

… " (1) что-то делается (возможно, есть операторы OpenSQL или вызов ФМ-ов in update task)
––––––––––––––––––––> где-то вне основного процесса 
                       (2) логирование (банальный insert в z-таблицу)
                       commit work только для (2)
… " (3) что-то продолжается делаться (возможно, будут еще SQL-выражения или update task)
" (4) commit или rollback (заранее не известно) для (1) и (3)

Есть ли какие-то способы реализовать задачу в таком виде?

ЗЫ.
1) Запуск ФМ-а логирования как starting new task или с помощью destination (в т.ч. in group) – не походит, т.к. происходит неявный коммит, и если в (1) был SQL-оператор, данные закоммитятся, хотя в (4) может оказаться роллбак
2) Создание диалогового задания с помощью job_open/job_close – не подходит, т.к. внутри job_open сидит db_commit.

[UPD]ЗЗЫ. Классические варианты с выполнением (2) до (1) или после (4) - очевидны, но нежелательны.

Кодер

Persistent serviceи Transaction service вам в помощь. если юзать именно их, тогда то, что вам нужно, получится.

trop

неявный commit сессии бд не так страшен

Бородин Игорь

LAT написал(а):

starting new task или с помощью destination (в т.ч. in group) – не походит, т.к. происходит неявный коммит

Вроде бы на вызов ФМ IN UPDATE TASK неявный коммит не действует, там нужен явный. Так, что если у вас шаги (1) и (3) реализованы через ФМ обновления, смело можете шаг (2) обернуть, например, в report (и делать submit), или в starting new task (как вы уже сказали).

LAT

Бородин Игорь написал(а):

...если у вас шаги (1) и (3) реализованы через ФМ обновления...

Спасибо - но увы

LAT

Кодер написал(а):

Persistent serviceи Transaction service вам в помощь. если юзать именно их, тогда то, что вам нужно, получится.

Насколько я понимаю, Transaction service – набор классов, который позволяет работать с LUW’ами в ОО-стиле. Упрощенно говоря, все SQL-операторы и вызовы ФМ-ов «in update task» оборачиваются в методы классов, потом, комбинируя вызовы этих методов, а также используя непосредственный запуск обновлений с помощью end(), обеспечивается выполнение обновлений в нужной последовательности. Но механизмы обновлений – те же самые, что и в «классическом» АБАП-программировании. И если мой фрагмент (1) (а также, чтобы не запутаться и всех не запутать - то и (3) и (4)) не обернуты с помощью методов классов Transaction service, то использование Transaction service для (2) заодно закоммитит изменения (1). Или я ошибаюсь?

Удав

LAT написал(а):

Т.е. во множестве мест уже существующего приложения реализовать следующую логику:

Code:

… " (1) что-то делается (возможно, есть операторы OpenSQL или вызов ФМ-ов in update task)
––––––––––––––––––––> где-то вне основного процесса 
                       (2) логирование (банальный insert в z-таблицу)
                       commit work только для (2)
… " (3) что-то продолжается делаться (возможно, будут еще SQL-выражения или update task)
" (4) commit или rollback (заранее не известно) для (1) и (3)

Есть ли какие-то способы реализовать задачу в таком виде?

Такую задачу нужно решать ДО (1). Тогда никаких проблем с COMMIT не возникнет.

LAT

Удав написал(а):

Такую задачу нужно решать ДО (1). Тогда никаких проблем с COMMIT не возникнет.

Знаю. Но интересует именно возможность реализации варианта именно с "автономным" LUW'ом (из 1-го поста).

Удав

LAT написал(а):

Но интересует именно возможность реализации варианта именно с "автономным" LUW'ом (из 1-го поста).

Зачем вы хотите поломать понятие LUW?

LAT

Почему сразу "поломать"? - отэнхансить

.

Бородин Игорь

Еще есть понятие Secondary Database Connections (доп.инструкция CONNECTION к Open-SQL):

Code:

INSERT ... CONNECTION con.
COMMIT CONNECTION con. 

сам не юзал

, но вроде бы то, что нужно:

Цитата:

Every database connection forms its own transaction context. This means that database changes on one connection can be saved (using COMMIT) or discarded (using ROLLBACK) independently of changes on other database connections. You can, for example, commit and store protocol data on a secondary database connection without affecting the running transaction on the standard R/3 database connection.

AFH

LAT написал(а):

Насколько я понимаю, Transaction service – набор классов, который позволяет работать с LUW’ами в ОО-стиле. Упрощенно говоря, все SQL-операторы и вызовы ФМ-ов «in update task» оборачиваются в методы классов, потом, комбинируя вызовы этих методов, а также используя непосредственный запуск обновлений с помощью end(), обеспечивается выполнение обновлений в нужной последовательности. Но механизмы обновлений – те же самые, что и в «классическом» АБАП-программировании. И если мой фрагмент (1) (а также, чтобы не запутаться и всех не запутать - то и (3) и (4)) не обернуты с помощью методов классов Transaction service, то использование Transaction service для (2) заодно закоммитит изменения (1). Или я ошибаюсь?

А всё-таки, это не то что вам нужно?

Цитата:

Subtransactions

You can create a subtransaction by starting a new transaction before another transaction has come to an end. Subtransactions must be ended within the transaction in which they are embedded. A COMMIT WORK is never triggered when a subtransaction is ended. Changes to the persistent objects of a subtransaction are only made when the top-level transaction is ended. This occurs explicitly in a COMMIT WORK or implicitly in an END, depending on the transaction mode. You can also query the transaction mode with IF_OS_TRANSACTION~GET_MODES for subtransactions, but the transaction mode always tells you the global setting of the Object Services for the current program.

...

In particular, the changes that were confirmed in object-oriented subtransactions with method END are made, whereas changes that were cancelled with UNDO are not affected. It could therefore be advisable to work with object-oriented (sub) transactions in classical applications as well in order to have access to an easy-to-use COMMIT/ROLLBACK mechanism.

По этому куску всё-таки не до конца понятно можно ли добиться такого поведения как вам нужно. Видимо придется попробовать.

LAT

AFH написал(а):

А всё-таки, это не то что вам нужно?

На словах в мануале - похоже, на деле - нет.

AFH написал(а):

По этому куску всё-таки не до конца понятно можно ли добиться такого поведения как вам нужно. Видимо придется попробовать.

В результате проб и родились уточняющие вопросы.

LAT

Бородин Игорь написал(а):

Еще есть понятие Secondary Database Connections

Спасибо, то, что нужно.

8051core

Если посмотреть код BAL_DB_SAVE, то он как раз через Secondary Database Connections и работает.

Code:

function bal_db_save.
*"----------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*"  IMPORTING
*"     VALUE(I_CLIENT) TYPE  SY-MANDT DEFAULT SY-MANDT
*"     VALUE(I_IN_UPDATE_TASK) TYPE  BOOLEAN DEFAULT SPACE
*"     VALUE(I_SAVE_ALL) TYPE  BOOLEAN DEFAULT SPACE
*"     VALUE(I_T_LOG_HANDLE) TYPE  BAL_T_LOGH OPTIONAL
*"     VALUE(I_2TH_CONNECTION) TYPE  BOOLEAN DEFAULT SPACE
*"     VALUE(I_2TH_CONNECT_COMMIT) TYPE  BOOLEAN DEFAULT SPACE

Правила форума

Можно ли выполнить SQL-операторы в новом LUW'е, не зацепив уже существующий?

Кто сейчас на конференции