Вызов ф.м. starting new task из perform on commit

sibrin

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

IMHO, самое подозрительное звено, через которое могут взаимодействовать LUW основного и асинхронного процесса -это call-back функция. Может вообще отказаться от ее использования, и поскольку процессы запускаются на одном сервере приложений, в качестве флага завершения асинхронного процесса использовать SAP memory через GET/SET PARAMETER?

Мысль неплохая, но, если не ошибаюсь, через export ... to memory id (ABAP memory) из асинхронного модуля ничего не передать.
А если использовать export ... to shared memry (cross-transaction application buffers), то вероятен конфликт, если в разных окнах транзакция запущена два раза.

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

Еще одна мысль, которую вроде здесь не поднимали, возможно глюк происходит на одном из серверов приложений, если их несколько в системе. Маловерятно, но...

Нет. В z-логи пишется добрая треть syst. Серверов несколько, но данная группа пользователй работает на одном. Процессы обновления запускаются на разных серверах. Но говорить о том, где они не запускаются бессмысленно.

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

PS: и еще, не ведется ли статистики, что глюк происходит в случае перекрытия процессов обновления от нескольких юзеров?

Процессы, использующие это OLE пересекаются не часто. Корреляции с глюками нет. А в целом ресурсов и, в частости, свободных процессов обновления в системе предостаточно.

vga

sibrin написал:

Code:

CALL FUNCTION 'TH_GET_VBKEY' IMPORTING VBKEY = vbkey1.
create object objref 'Z.MyCoolCOMObject'.
CALL FUNCTION 'TH_GET_VBKEY' IMPORTING VBKEY = vbkey2.

даёт vbkey1 <> vbkey2 в ~20% случаев!

Наверно уже утомил своими предположениями, :-)

но жаль у себя не попробовать, нет такого FM

А может все же изменение vbkey связано с временной задержкой на создание объекта. Как понимаю, create object посылает rfc запрос на клиента и во время этого временого лага кто-то вклинивается.

Если так написать: create object objref 'Z.MyCoolCOMObject' no flush наверно ключ не изменится

sibrin

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

А может все же изменение vbkey связано с временной задержкой на создание объекта. Как понимаю, create object посылает rfc запрос на клиента и во время этого временого лага кто-то вклинивается.

Существуют успешные случаи, когда создание OLE объекто длилось дольше, чем в неуспешных.

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

Если так написать: create object objref 'Z.MyCoolCOMObject' no flush наверно ключ не изменится

Ну, после первого же вызова метода OLE-объекта всё равно придётся flush сделать, т.к. метод возвращает данные.

sibrin

Code:

data: vbkey1 type vbkey_d
    , vbkey2 type vbkey_d
    .
CALL FUNCTION 'TH_GET_VBKEY'
 IMPORTING
   VBKEY         = vbkey1.

* * * вызов aRFC и ожидание результата * * *

  CALL FUNCTION 'TH_GET_VBKEY'
    IMPORTING
      vbkey = vbkey2.

  IF vbkey1 <> vbkey2.
    DATA: lt_vbmod TYPE TABLE OF vbmod
        , lt_vbdata TYPE TABLE OF vbdata
        .
    FIELD-SYMBOLS: <vbmod> TYPE vbmod
                 , <vbdata> TYPE vbdata
                 .
    SELECT *
      INTO TABLE lt_vbmod
      FROM vbmod
      WHERE vbkey = vbkey1.
    SELECT *
      INTO TABLE lt_vbdata
      FROM vbdata
      WHERE vbkey = vbkey1.

    LOOP AT lt_vbmod ASSIGNING <vbmod>.
      <vbmod>-vbkey = vbkey2.
    ENDLOOP.
    LOOP AT lt_vbdata ASSIGNING <vbdata>.
      <vbdata>-vbkey = vbkey2.
    ENDLOOP.

    INSERT vbmod FROM TABLE lt_vbmod ACCEPTING DUPLICATE KEYS.
    INSERT vbdata FROM TABLE lt_vbdata ACCEPTING DUPLICATE KEYS.
    DELETE FROM vbmod WHERE vbkey = vbkey1.
    DELETE FROM vbdata WHERE vbkey = vbkey1.

    CALL FUNCTION 'DB_COMMIT'.
  ENDIF.

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

Ой не доведут до добра такие методы...

vga

sibrin написал:

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

А может все же изменение vbkey связано с временной задержкой на создание объекта. Как понимаю, create object посылает rfc запрос на клиента и во время этого временого лага кто-то вклинивается.

Существуют успешные случаи, когда создание OLE объекто длилось дольше, чем в неуспешных.

ИМХО, не показательно, если следовать данному предположению, вклинивание носит случайный характер, иногда и в меньший промежуток попадает, иногда и в течении более длительного не проявляет себя. Найти бы какой параллельный процесс сбивает vbkey. Вообщем тяжелый случай, без реальных данных только гадать.

sibrin написал:

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

Если так написать: create object objref 'Z.MyCoolCOMObject' no flush наверно ключ не изменится

Ну, после первого же вызова метода OLE-объекта всё равно придётся flush сделать, т.к. метод возвращает данные.

Это все так, просто для примера написал, что вероятно инцидент происходит именно во время rfc обмена.

sibrin

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

Ой не доведут до добра такие методы...

Если всё равно ничего не работает, то куда уж хуже-то?

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

sibrin, как только ты вызвал aRFC - у тебя произошел неявный DB commit.
Что тут дальше то обсуждать?

Может стоит подумать над альтернативными методами решения?

sibrin

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

sibrin, как только ты вызвал aRFC - у тебя произошел неявный DB commit.
Что тут дальше то обсуждать?

Однако ж ведь нашлось что обсуждать.
Три страницы накатали. Причём, весьма уважаемые коллеги приняли участие в дискуссии, за что им огромное спасибо.

В общем, проблема локализовалась.
И хотя нота 849693 на нашем уровне базиса давно присутствует и отношения к текущей ситуации не имеет, тем не менее понятно, что проблема kernel'а и самодельного OLE-объекта.

Будем писать в SAP AG, но на скорый ответ, да и вообще, на решение проблемы, рассчитывать не приходится.

sibrin

Интересное наблюдение: когда открываются/закрываются SAP LUW в рамках одной внутренней сессии, то на единичку увеличивается 4-й слева байт vbkey. Если вызывать другую внутреннюю сессию (call transaction, submit), то этот байт может прибавить десяток. То же самое, если запустить программу два раза подряд.

Когда происходит глюк, то меняются сразу несколько байт с 3-го по 8-й.

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

Цитата:

проблема kernel'а

0,(0)1%. Ни один стандартный OLE объект не приводит к таким интересным ситуациям. Иначем бы САП ошибку уже исправил.

Цитата:

самодельного OLE-объекта

Возможно. Но я не понимаю каким образом этот OLE объект может влиять на SAP LUW.
Можно узнать что делает этот объект? Он, часом, не обращается к БД?

sibrin

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

Ни один стандартный OLE объект не приводит к таким интересным ситуациям. Иначем бы САП ошибку уже исправил.

1) Много ты знаешь систем, где в MB_DOCUMENT_BADI используется OLE-объект?
2) Есть такие ошибки в базисе SAP, которые уже лет 5 исправить не могут.
3) Вот совсем свеженькая нота: 1076804 от 27.09.2007, которая гласит, что VBKEY может меняться, когда включена трассировка ST01/ST05. Данная нота предназначена для версий с 4.6D до 7.10! Сколько лет понадобилось, чтобы ошибку исправить? Ну да, возможно не с рождения 4.6D она появилась, а привнеслась туда каким-то сервис-паком. Тем не менее, веских оснований, чтобы писать нули в периоде я не вижу.

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

Но я не понимаю каким образом этот OLE объект может влиять на SAP LUW.

4) В том-то и дело, что напрямую не может никак. Только посредством GUI. Поэтому, в первую очередь, это ошибка ядра.

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

Можно узнать что делает этот объект? Он, часом, не обращается к БД?

Да, он обращается к БД.

vga

sibrin написал:

Когда происходит глюк, то меняются сразу несколько байт с 3-го по 8-й.

У Вас исходники OCX есть? Она случаем обратной сессии не открывает? :lol:

sibrin

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

У Вас исходники OCX есть?

Да.

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

Она случаем обратной сессии не открывает? :lol:

Нет.
Впрочем, не уверен на 100%, что это вообще всегда лишено смысла.
Если я не ошибаюсь, OLE объект выполняется под управлением Windows в отдельном процессе в собственной области памяти, так что теоретически может открыть и обратную сессию.

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

Code:

Много ты знаешь систем, где в MB_DOCUMENT_BADI используется OLE-объект?

Нет. Но я знаю множество систем, в которых OLE объекты никак не влияют на LUW.

Цитата:

Есть такие ошибки в базисе SAP, которые уже лет 5 исправить не могут.

Согласен. Но все равно, чтобы грешить на ядро - необходимо иметь веские основания. Которых я, пока, не вижу.

Касательно OLE:
в зависимости от технологии связывания OLE объект будет размещен в адресном пространстве программы-клиента либо сам(1), либо как интерфейс для обмена данными с OLE сервером(2).

Что касается сессий и БД:
в ситуации (1), когда OLE объект лезет в базу, откроется новая сессия в рамках приложения-клиента. Иначе - на стороне OLE-сервера. И дальше все зависит от следующего: к каким объектам БД обращаются обе сессии, пишет OLE объект или только читает, что за СУБД, уровень изоляции обеих сессий.
Т.е. сессии вполне себе могут оказаться конкурентными друг другу -> может произойти конфликт сессий -> пробемы в SAP LUWe.

Надо смотреть логи БД, вообщем.

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

Вызов ф.м. starting new task из perform on commit

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