COMMIT WORK: Timing of DB commit and update modules

Question

Hi all,
Does anyone know categorically the order of starting the asynchronous update modules (CALL FUNCTION ... IN UPDATE TASK) and the database commit, when a COMMIT WORK is done?
Does COMMIT WORK:
- Do PERFORM ... ON COMMIT
- Start asynchronous update processing
- Do database commit
Or does it:
- Do PERFORM ... ON COMMIT
- Do database commit
- Start asynchronous update processing
My reason for asking is some code (not written by me!) that essentially raises CREATED workflow events in the update task, but performs the corresponding database inserts in the current work process.
It looks like we are getting the situation that sometimes the table entries do not exist when the update modules exist, which in turn suggests to me that perhaps the asynchronous update modules are started just before the database commit that is done when a COMMIT WORK statement is executed.
Cheers,
Scott

Answer 1

Christian,
Before the update module execution.  Here's some code to highlight and let's assume it runs in a dialog process. And to everyone else, yes, I know this is a poor way to implement updates!
INSERT INTO zmyobject VALUES lv_myobject.
CALL FUNCTION 'SWE_EVENT_CREATE_IN_UPD_TASK'
  IN UPDATE TASK
  EXPORTING
    objtype = 'ZMYOBJECT'
    objkey  =  lv_myobject-key
    event   = 'CREATED'.
COMMIT WORK.
So I meant to ask the question of whether we could guarantee that the new record in table ZMYOBJECT would be committed to the database <i>before</i> the update module was executed. It really is a theoretical question though it did not begin as one.
I do not believe the answer to this problem can be determined by debugging, because given that these two steps occur so close in time to one another, by the time the update module appeared in the debugger, it would be unrealistic to expect that the DB insert performed in the dialog process had not been committed yet.
I might be wrong, but I really don't think you're going to find ABAP logic embedded in SAPMSSY0 or elsewhere that invokes the update modules or performs a DB commit. Rather, it is my suspicion that the COMMIT WORK statement works like this:
- Drop into the kernel
- Does a callback to SAPMSSY0 to execute form %_BEFORE_COMMIT to raise a static OO event
- Does a callback to SAPMSSY0 to execute form %_COMMIT and thereby process any PERFORM ... ON COMMIT
- Does a database commit
- Does a callback to SAPMSSY0 to execute form %_AFTER_COMMIT to raise another static OO event
Further, I believe that it is the database commit that now makes the queued CALL FUNCTION ... IN UPDATE TASK now visible in VBLOG to other processes.
Lastly, and this is of course wild speculation, I suspect that it is an update process running somewhere else that detects the new entries in VBLOG and grabs them for processing.
So, I'm kind of changing my position from earlier to state that I believe the COMMIT WORK statement does not directly trigger the update modules at all, rather it just does the database commit and this makes visible the pending update modules to the dispatcher / update work processes which probably grab the update LUW's on a first come first served basis.
At least, that is how I would design it :-).
Cheers,
Scott