Автономная транзакция.

east

Доборго времени суток!

Как можно организовать автономную транзацию?

east

Друзья, есть идеи?

Необходимо писать лог вне зависимости от того commit-ом или rollbackом завершится основная транзакция.

sy-uname

east написал:

Друзья, есть идеи?

Необходимо писать лог вне зависимости от того commit-ом или rollbackом завершится основная транзакция.

db_commit или rfc вызов на выбор.

east

sy-uname написал(а):

db_commit или rfc вызов на выбор.

1.db_commit - дает database commit на Native SQL.
2.rfc вызов ничего не дает. Коммитятся все данные, как и в пункте №1.

Code:

Function ZTEST1 .
*"----------------------------------------------------------------------
*"*"Local Interface:
*"----------------------------------------------------------------------
  Data: ls_tab1 Type ztest1.
  Data: dest Type rfcdest value 'TEST@DEV.DOMAIN_DEV'. "коннект к текущей системе.
  Data: lv_x Value 1.
  Select Max( tabix ) From ztest1 Into ls_tab1-tabix.
  ls_tab1-tabix = ls_tab1-tabix + 1.
  ls_tab1-param = space.
  Modify ztest1 From ls_tab1.
  Call Function 'ZTEST2' Destination dest.
  Rollback Work.
EndFunction.

Code:

Function ZTEST2.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"----------------------------------------------------------------------
  Data: ls_tab2 Type ztest2.
  Select Max( tabix ) From ztest2 Into ls_tab2-tabix.
  ls_tab2-tabix = ls_tab2-tabix + 1.
  ls_tab2-param = gc_x.
  Modify ztest2 From ls_tab2.
  Commit Work.
EndFunction.

Мне требуется сделать так, чтоб commit work в ФМ ztest2 влиял на базу только для изменений, внесенных в этом модуле.

Пономарев Артем

CL_OS_TRANSACTION

ArmAnn

Пример у вас не очень корректный - неявный db commit происходит при RFC-вызове, т.е. Rollback после вызова уже ничего не откатит.
Если модифицировать таблицу БД не явно Modify ztest1 From ls_tab1., а посредством модуля обновления - то такая схема скорее всего будет работать. Правда проверять мне лень - уже 17.48 пятницы

UPD. А в rfcdest можно писать не TEST@DEV.DOMAIN_DEV, а NONE

sy-uname

east написал:

1.db_commit - дает database commit на Native SQL.

Да, именно. Поэтому его и рекомендовал.

Цитата:

2.rfc вызов ничего не дает. Коммитятся все данные, как и в пункте №1.

...
Мне требуется сделать так, чтоб commit work в ФМ ztest2 влиял на базу только для изменений, внесенных в этом модуле.

Так Вы делайте как рекомендует SAP, а не по "наколеночной" технологии.
Для обновления данных используйте специальные ФМ или подпрограммы, вызываемые через соответственно on update task или perform on commit/
Тогда Вам и неявный db_commit при rfc вызове не будет мешать сделать rollback, и в ztest2 данные попадут (автономно-транзакционно)..

east

ArmAnn написал:

Пример у вас не очень корректный - неявный db commit происходит при RFC-вызове, т.е. Rollback после вызова уже ничего не откатит.
Если модифицировать таблицу БД не явно Modify ztest1 From ls_tab1., а посредством модуля обновления - то такая схема скорее всего будет работать.

Про неявный db commit упустил.. А вот про модули обновления не вполне...

Code:

Set Update Task Local.
Call Function 'FUNCNAME' In Update Task. 
...
Call Function 'ZTEST2' Destination NONE.
...
Commit work. 

?

Пономарев Артем написал:

CL_OS_TRANSACTION

Спасибо. Проверю.

east

sy-uname написал(а):

Так Вы делайте как рекомендует SAP, а не по "наколеночной" технологии.
Для обновления данных используйте специальные ФМ или подпрограммы, вызываемые через соответственно on update task или perform on commit/
Тогда Вам и неявный db_commit при rfc вызове не будет мешать сделать rollback, и в ztest2 данные попадут (автономно-транзакционно)..

Интересно.. А если я в User-Exit-е?

Пономарев Артем

east, вам совсем не нужен SET UPDATE TASK LOCAL. Наоборот, вам необходимо разнести выполнение разных участков кода. А вы их упорно скрещиваете в одном LUW.

sy-uname

east написал:

Интересно.. А если я в User-Exit-е?

Тем более это справедливо для User-Exit-а.

ArmAnn

Code:

Function ZTEST1 .
*"----------------------------------------------------------------------
*"*"Local Interface:
*"----------------------------------------------------------------------
  Data: ls_tab1 Type ztest1.
  Data: lv_x Value 1.
  Select Max( tabix ) From ztest1 Into ls_tab1-tabix.
  ls_tab1-tabix = ls_tab1-tabix + 1.
  ls_tab1-param = space.
*  Modify ztest1 From ls_tab1.
  Call Function 'FUNCNAME' In Update Task.

  Call Function 'ZTEST2' Destination 'NONE'.
  Rollback Work.
EndFunction.

Code:

Function FUNCNAME.
 Modify ztest1 From ls_tab1.
EndFunction.

Code:

Function ZTEST2.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"----------------------------------------------------------------------
  Data: ls_tab2 Type ztest2.
  Select Max( tabix ) From ztest2 Into ls_tab2-tabix.
  ls_tab2-tabix = ls_tab2-tabix + 1.
  ls_tab2-param = gc_x.
  Modify ztest2 From ls_tab2.
* Commit Work.
  call  function 'DB_COMMIT'.
EndFunction.

пояснения:
1. вместо Modify ztest1 From ls_tab1. вы зовете модуль обновления FUNCNAME, который разумеется будет выполнен только после COMMIT WORK
2. при вызове ФМа ZTEST2 происходит коммит текущей транзакции БД
3. при операции modify в ФМе TEST открывается новая транзакция БД и пишутся данные в таблицу ztest1
4. эта транзакция комиттится ФМом 'DB_COMMIT'. Все, данные лога сохранены в БД. Дальнейший ROLLBACK WORK над этими данными уже силы не имеет

DKiyanov

2 ArmAnn ИМХО без разницы что писать в "Function ZTEST2." "Commit Work." или "call function 'DB_COMMIT'." они ведь всё равно в Destination 'NONE'.

2 east есть ещё варианты записи лога в файл OPEN DATASET... оно commit work не вызывает и roll back-ом не откатывается
ещё можно попробовать использовать EXPORT...SHARED BUFFER..

ArmAnn

DKiyanov написал:

ИМХО без разницы что писать в "Function ZTEST2." "Commit Work." или "call function 'DB_COMMIT'." они ведь всё равно в Destination 'NONE'.

По моему тоже, но на 100% не уверен, поэтому и написал с DB_COMMIT. Так оно точно сработает

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

Автономная транзакция.

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