Does after call function 'xxx' in update task will DEQUEUE enqueued tbl?

[Former Member]

Hi All,

I am facing problem while using "in update task" function with my existing locking object. Hopefully somebody could enlighten my doubt.

I use structure table 'STRCUTUREA' to lock(enqueue) in Changes Mode for whole program. So, at the same time, nobody can do modify operation. I update some tables which is need atomic operations, then I call an update function module that will update 4 tables all at once. Let say, function "ZDO_POST" will have:

call function 'ZUPD_TABLE1' in update task
    exporting
      upd_mode = gd_update_mode
    tables
      tab      = gt_table1.

call function 'ZUPD_TABLE2' in update task
    exporting
      upd_mode = gd_update_mode
    tables
      tab      = gt_table2.

call function 'ZUPD_TABLE3' in update task
    exporting
      upd_mode = gd_update_mode
    tables
      tab      = gt_table3.

call function 'ZUPD_TABLE4' in update task
    exporting
      upd_mode = gd_update_mode
    tables
      tab      = gt_table4.

commit work and wait.

Why after do "CALL FUNCTION 'XXXX' IN UPDATE TASK", system dequeue my locking object 'STRCUTUREA'? (Check to SM12, locking object 'STRCUTUREA' is unlocked). By the way, I still in Changes mode at that moment and I never call dequeue function after saving.

Does 'IN UPDATE TASK' will DEQUEUE all existing locking object after update task is processed (VBLOG --> Commit work)?

My 'STRCUTUREA' (for locking) uses different structure than 4 tables above.

Note: If I come with normal function module operation (without IN UPDATE TASK parameter), my enqueued object 'STRCUTUREA' will still remain after save operation is performed.

Does any body could explain to me?

Thanks before.

Best regards,

Dondi.

Edited by: Dinivian Dondi on Oct 14, 2011 2:18 PM

[arseni_gallardo]

Dinivian,

In the function module you are using for the enquee ('ENQUEUE_Exxx') you will find an optional parameter called _SCOPE (default value = 2). Use _SCOPE = 1 and try again.

If you go to transaction SE11 and press F1 on the Lock Object field you'll see the documentation. Click on 'Sap Lock Concept' and you will see this explanation:

  Duration of an SAP lock
    At the end of a transaction, this automatically releases all the SAP
    locks it holds. Note, however, that if an update routine is called by
    the transaction, locks can be transferred from the ordering transaction
    to the update routine. In the same way, these locks are automatically
    released at the end of the update routine.
    Via the IMPORT parameter _SCOPE of the ENQUEUE module, you can determine
    whether a lock should be transferred to the update routine if one is
    called.
    If _SCOPE has the value '1', the lock remains with the the ordering
    transaction. If _SCOPE has the value '2', the lock can pass to the
    update routine. Finally, if the parameter has the value '3', two locks
    of the same kind will be generated, one of which passes to an update
    routine when one is called.
    By calling the DEQUEUE module, a transaction can explicitly release a
    lock which it holds. The lock parameter and lock mode must be supplied
    with the same value as for calling the ENQUEUE module. If the parameter
    _SCOPE has the value '1', only one lock is released which cannot pass to
    an update routine. If the parameter has the value '2', only one lock is
    released which can pass to the update program. Finally, if the parameter
    has the value '3', both locks can be released. Note however that a
    transaction can release neither a lock which has already been
    transferred to the update program, nor a lock which is held by another
    transaction.
    Via the IMPORT parameter _SYNCHRON you can control whether the release
    of the lock should be synchronous or asynchronous. If this parameter has
    the value 'X', the module waits until the lock has really been removed
    from the lock table. If the parameter has the value ' ', a requst for
    deletion of the lock from the lock table is sent to the application
    server which manages the lock table, and then the execution of the
    program is immediately continued.

Edited by: Arseni Gallardo on Oct 14, 2011 3:14 PM

[Former Member]

Hi Arseni,

Thanks for your explanation. It works now!.

Yeah, I got a better comprehension then.

Regards,

Dondi.

[RaymondGiuseppi]

As wrote (*), the ENQUEUE life is related top the _SCOPE parameter used in the CALL, The COMMIT WORK will release the locks as a COMMIT WORK is usually the end of the transaction (update data, release locks and go back to initial screen)

- End of update task will dequeue their own inherited locks

- DEQUEUE modules can be usually replaced by COMMIT or ROLLBACK work.

Read some documentation like [The SAP Lock Concept (BC-CST-EQ)|http://help.sap.com/saphelp_nw04/helpdata/en/c2/2d7037ecc92a7ee10000009b38f8cf/frameset.htm] and [Updates in the SAP System (BC-CST-UP)|http://help.sap.com/saphelp_nw04/helpdata/en/5f/6f8337dd34ca76e10000009b38f8cf/frameset.htm] or [(ABAP) Update Techniques|http://help.sap.com/saphelp_nw04/helpdata/en/41/7af4cba79e11d1950f0000e82de14a/frameset.htm]

Regards,

Raymond

(*) read [Function Modules for Lock Requests|http://help.sap.com/saphelp_nw04/helpdata/en/cf/21eebf446011d189700000e8322d00/frameset.htm] and [COMMIT WORK|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm] reference documentation (look for "locks")

[Former Member]

Hi Raymond,

Thanks for the reference. It really helpful.

Regards,

Dondi.