"Commit work and wait" possible with JCA/JRA ?

Is it possible to specify the "commit and wait" directive with Java when attempting to commit a transaction via an RFC ? I am using JCA/JRA. If it is not possible with this version of JCA/JRA, will it be implemented in the next version ?
Thanks in advance,
Mark

No, apparently it is not as simple as that
An abap programmer explained to me that there is
a difference between the 'commit' and 'commit and wait'
directives; the former is asynchronous, the latter synchronous.
When I call commit() on the UserTransaction object, I believe I am calling the asynchronous 'commit', whereas what I want is to call the synchronous version via the JCA api.
Thanks,
Mark

Similar Messages

Issue with Commit Work and Wait.

Hi All,
None of the programs are working in my system which are calling BAPI BAPI_TRANSACTION_COMMIT.
On COMMIT WORK AND WAIT statement, the process is going into indefinite loop. Everything was fine till last Thursday and there are no updates or patch level change or notes applied in the system.
Please advice.

<div style="text-align:left">We tried everything but still the issue is there.</div>
Normally it's much easier to get help if you try to be as detailed as possible when explaining the problem and what exactly you have tried. No offense, but tried everything most likely translates into almost everything...
Some information/checks I'd be looking for:
<ul style="list-style:square!important">
<li>What functions are (or coding is) involved? Are they all standard or custom?</li>
<li>Have you tried update debugging and/or the usual traces (runtime analysis, SQL trace, etc.)?</li>
<li>What do you see in the process overview?</li>
<li>What about system log, developer trace, database logs/alerts, etc.?</li>
</ul>
Obviously my list is much too short and incomplete - yours must be longer. If you share your results (including your exchange with SAP) I suspect you have a better chance (though of course no guarantee) of somebody providing a valuable clue.
Not sure if it's just me, but the part that sounds so odd and suspicious is that you only mention commits via BAPI_TRANSACTION_COMMIT. As this is just a wrapper around a COMMIT WORK I'm tempted to think it's the functionality that's invoked before (i.e. linked to the registered update functions/modules). Without any additional knowledge though, my first shot was for general update problems (which you ruled out).

BAPI_REQUISITION_CREATE Problem with COMMIT WORK AND WAIT

I ran into an issue and wanted to get your opinions about what might be happening.
This is my original code that did not work correctly using COMMIT WORK AND WAIT. After the select statement, lv_count was zero even though there were PR items that had been created. I'm thinking that the database update was not complete, but why would that be?
    CALL FUNCTION 'BAPI_REQUISITION_CREATE'
      IMPORTING
        number            = lv_number
      TABLES
        requisition_items = gt_reqitem
        return            = gt_return.
*   Purchase requisition has been created
    IF lv_number IS NOT INITIAL.
      COMMIT WORK AND WAIT.
*     Get number of items in PR
      SELECT COUNT( DISTINCT bnfpo ) INTO lv_count
        FROM eban
        WHERE banfn = lv_number.
This is my corrected code that works. I removed the AND WAIT from the commit statement and added a separate wait statement. I now get the correct number of PR items that were created.
    CALL FUNCTION 'BAPI_REQUISITION_CREATE'
      IMPORTING
        number            = lv_number
      TABLES
        requisition_items = gt_reqitem
        return            = gt_return.
*   Purchase requisition has been created
    IF lv_number IS NOT INITIAL.
      COMMIT WORK.
      WAIT UP TO 1 SECONDS.
*     Get number of items in PR
      SELECT COUNT( DISTINCT bnfpo ) INTO lv_count
        FROM eban
        WHERE banfn = lv_number.
Any ideas?
Brenda

Brenda Bankert wrote:
Yes, I was able to see the message in RETURN and no, I am not calling the FM in a loop. My program calls it one time.
> Brenda
If you were able to see the message 'Purchase requisition number & created' it means that the macro macro_end is getting executed within which the COMMIT WORK statement is encapsulated.
I have quickly developed a dirty program to test the behaviour of 'SET UPDATE TASK LOCAL' and it seems to work as expected.
Everytime I executed the below program with 'SET UPDATE TASK LOCAL', I see the value of lv_count as 1000, however if I execute the below program with out the statement 'SET UPDATE TASK LOCAL' the value of count varies everytime, typically around 10 - 15, however the database is successfully updated with all the 1000 entries, this makes me believe that the 'SET UPDATE TASK LOCAL' statement will infact make the subsequent COMMIT synchronous.
REPORT zytest.
DATA:
ls_zytest    TYPE zytest,
ls_db_zytest TYPE zytest,
lv_numc04    TYPE numc4 VALUE 1001,
lv_count     TYPE i,
lv_index     TYPE i.
DO 1000 TIMES.
lv_index = sy-index.
CLEAR ls_zytest.
lv_numc04 = lv_numc04 + 1.
CONCATENATE 'KF00' lv_numc04 INTO ls_zytest-keyfield1.
CONCATENATE 'KF00' lv_numc04 INTO ls_zytest-keyfield2.
SET UPDATE TASK LOCAL.
CALL FUNCTION 'ZYTEST_BAPI'
    EXPORTING
      is_zytest = ls_zytest.
SELECT SINGLE * FROM zytest INTO ls_db_zytest WHERE keyfield1 = ls_zytest-keyfield1
                                                  AND keyfield2 = ls_zytest-keyfield2.
IF sy-subrc IS INITIAL.
    WRITE:/ lv_index, ls_db_zytest-keyfield1,ls_db_zytest-keyfield2.
    lv_count = lv_count + 1.
ENDIF.
ENDDO.
WRITE:/ lv_count.
FUNCTION zytest_bapi .
*"*"Local Interface:
*" IMPORTING
*"     REFERENCE(IS_ZYTEST) TYPE ZYTEST
DATA: transaction_id LIKE arfctid.
clear transaction_id.
macro_start.
CALL FUNCTION 'ZYTEST_UPDATE' IN UPDATE TASK
    EXPORTING
      is_zytest = is_zytest.
macro_end.
ENDFUNCTION.
FUNCTION ZYTEST_UPDATE.
*"*"Update Function Module:
*"*"Local Interface:
*" IMPORTING
*"     VALUE(IS_ZYTEST) TYPE ZYTEST
INSERT zytest from is_zytest.
ENDFUNCTION.
definition of the database table 'ZYTEST'
MANDT     MANDT
KEYFIELD1     CHAR20
KEYFIELD2     CHAR20
NONKEYFIELD     CHAR50
-Rajesh

DUMP with Commit work and wait

Hi all!! I need your help again!!
I have this:
WAIT UP TO 1 SECONDS.
                      UPDATE zpsc_ofertes
                      SET status = 'ENTRA'
                          status_v = 'CO/AA'
                      WHERE oferta = zpsc_ofertes-oferta
AND versio = var_vers_destino.
CALL FUNCTION 'STATUS_UPDATE_ON_COMMIT'.
    COMMIT WORK AND WAIT.
CALL FUNCTION 'BUFFER_REFRESH_ALL'
That code creates a dump... Why could be this problem??
Thanks!!

Let's see.
The current application triggered a termination with a short dump.
¿Qué ha sucedido?
The current application program detected a situation which really
should not occur. Therefore, a termination with a short dump was
triggered on purpose by the key word MESSAGE (type X).
¿Qué puede hacer?
Print out the error message (using the "Print" function)
and make a note of the actions and input that caused the
error.
To resolve the problem, contact your SAP system administrator.
You can use transaction ST22 (ABAP Dump Analysis) to view and administer
termination messages, especially those beyond their normal deletion
date.
The code...
000010   *
000020   ***INCLUDE LPS_BAPIF01 .
000030   *
000040   *&
000050   *&      Form CHK_PRECOMMIT
000060   *&
000070   *       check precommit
000080   *
000090   FORM chk_precommit.
000100
000110     DATA: chk_precommit_ok TYPE c,
000120           chk_error        type c.
000130
000140     CALL FUNCTION 'PS_FLAG_GET_GLOBAL_FLAGS'
000150          IMPORTING
000160               e_precommit_ok = chk_precommit_ok
000170               e_error        = chk_error.
000180
000190     IF chk_precommit_ok = space.
000200   *   Precommit wurde noch nicht aufgerufen.
     >       MESSAGE x030(cnif_pi).
000220     ELSEIF chk_precommit_ok <> 'Y'.
000230   *   Precommit wurde nicht erfolgreich durchlaufen.
000240       MESSAGE x033(cnif_pi).
000250     elseif not chk_error is initial.
000260   *   At least one single BAPI failed
000270       MESSAGE x056(cnif_pi).
000280     ENDIF.
000290
000300   * commit work was called successfully after the precommit
000310     PERFORM ps_bapi_init_global_variables.
000320
000330   ENDFORM.                    " CHK_PRECOMMIT
000340

"Problem" with COMMIT WORK AND WAIT

Hi everyone!
I'm facing the following situation:
I have a Z program that calls MIGO, via CALL TRANSACTION. The only thing I do when calling this is filling a few fields, so the user has to complete the operation before going back to Z program.
When someone executes MIGO in the normal way, I mean, without a CALL TRANSACTION command, there was a additional step, a modification made in the standard code for someone before. But this part of the code didn't execute when calling MIGO via CALL TRANSCATION.
What I have found out is that just before this code inserted, there was a COMMIT WORK AND WAIT command, and was exactly in this point that, when using the first aproach, it leaves MIGO.
Is there a way to execute the entire process in MIGO, I mean , do not leave it at COMMIT command? I've tried to pass at CALL TRANSACTION command diferent UPDATE parameters (i.e: 'S', 'A' and 'L'), but it didn´t work as well.
I hope you could get the point!
Thanks in advance!
Raphael

I've just found out something interesting about that.
When I make a CALL TRANSACTION, without passing a table bdcdata, the transaction doesn't leave at the COMMIT WORK command.
So, I think it won't work with the bdcdata!
Raphael

COMMIT WORK AND WAIT does not work

Hello,
I know this question has been asked many times in various forums. But the fact remains that there is no definitive solution found for this problem which does not involve WAIT UP TO n SECONDS or SELECT until the DB commit has been completed.
We have an IDoc based inbound interface for creating Project Defintion and WBS Elements. Here is how the code looks like in the processing function module:
* Create Project Defintion
CALL FUNCTION 'BAPI_PROJECTDEF_CREATE'
EXPORTING
    project_definition_stru = lwa_proj_bapi
TABLES
    e_message_table         = lt_messages.
* If no errors
CALL FUNCTION 'BAPI_TRANSACTION_COMMIT'
EXPORTING
    wait = 'X'.
* Other code
* Create WBS Element (BAPI could not be used because not all fields are allowed to be updated)
CALL TRANSACTION 'CJ11'
Now while creating the WBS Element, transaction CJ11 returns an error that 'Project does not exist'. This is not correct because the same Project was successfully created in the previous step.
It is clear that the problem is because of the delay in database commits.
This happens only with few IDoc's and not all of them. And of course, the problem does not occur if I induce WAIT UP TO n SECONDS after BAPI_TRANSACTION_COMMIT. But this is not the best practice.
The question is why BAPI_TRANSACTION_COMMIT does not wait even though we are forcing it to?
Thanks in advance
Sagar Acharya

Suhas wrote:
But i am baffled that although the COMMIT has happened earlier why is the data not updated in the DB ?
Well, it's just a [COMMIT WORK|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm] and not a [COMMIT WORK AND WAIT|http://help.sap.com/abapdocu_70/en/ABAPCOMMIT.htm#@@AND%20WAIT@@COMMIT%20WORK@@]. Let me quote the ABAP help:
If you do not specify the addition AND WAIT, the program does not wait until the update work process has executed it (asynchronous updating), but instead is resumed immediately after COMMIT WORK. However, if the addition AND WAIT is specified, program processing after COMMIT WORK will not continue until the update work process has executed the high-priority update function modules (synchronous updating).
@Sagar Acharya: Well, I thought you were looking for an explanation why sometimes the project isn't created (and you only had posted coding that showed details for step 1) - I'm trying hard, but my mind reading skills are rather limited yet...
So let's think about step 2 and 3: I assume that you made sure that your coding always references the correct WBS element. Again the commit (without wait) is done already via CJ11 (e.g. check form BUCHEN in SAPLCJWB). I'd expect though that the synchronous update mode should make this work. Since it doesn't, I'd try local update mode, which is what I'd choose in your case anyhow.
Apart from that my mind is pretty blank, except for the usual silly things to check. E.g. are you sure you're coding is correct, you are handling all return messages and log them for inspection later (e.g. application log), you are certain that the WBS was actually created by the same IDoc that throws the fit (and IDoc was not reprocessed), etc.
So maybe somebody else has better ideas...

Purpose of Commit work and wait

Hi Friends,
Kindly let me know what is the Exact Purpose of Commit work and wait
Akshitha.

Hai,
<b>COMMIT WORK</b>
This is the standard form, which specifies asynchronous processing. Your program does not wait for the requested functions to finish processing.
<b>COMMIT WORK AND WAIT</b>
This form specifies synchronous processing. The commit statement waits for the requested functions to finish processing. Control returns to your program after all high priority (V1) function modules have run successfully.
The AND WAIT form is convenient for switching old programs to synchronous processing without having to re-write the code. Functionally, using AND WAIT for update-task updates is just the same as dialog-task updates with PERFORM ON COMMIT.
Regards,
Padmam.

COMMIT WORK AND WAIT

Message opened on behalf of colleague:
I just have a quick inquiry regarding COMMIT WORK AND WAIT, I
understand that this method performs the following:
"This form specifies synchronous processing. The COMMIT statement waits
for the end of processing. Control returns to your program after all
high priority (V1) function modules have run successfully."
"The AND WAIT form is convenient for switching old programs to
synchronous processing without having to re-write the code.
Functionally, using AND WAIT for update-task updates is just the same
as dialog-task updates with PERFORM ON COMMIT."
It says that before doing the actual commit it will wait for the end of
processing for all related updates against the transaction. However
does it also wait for any "user exits" to finish or does it go ahead
and performs the commit and updates then the user exit happens?
Thanks.

Hi User exit is part of the transaction where you call a subroutine, or another function module or BADI method. So in my opinion it will wait. Unless there is a explicit commit work coded inside the user exit.
regards,
Advait

COMMIT WORK AND WAIT USE

Hi Friends,
what is mean by COMMIT WORK AND WAIT.
when we use ths syntax...??
situation pls.
regards,
venu.

Hi,
To apply the changes made to the runtime objects of persistent classes to the actual persistent objects in the database, execute the COMMIT WORK statement. (Alternatively, use COMMIT WORK AND WAIT or SET UPDATE TASK LOCAL). Unless you are executing an object-oriented transaction from within the Transaction Service, you must include the COMMIT WORK statement explicitly in the program. Otherwise, it is encapsulated in the Transaction Service. (If you explicitly include the COMMIT WORK statement as described here, the t op-level transaction runs in compatibility mode).
The function of the COMMIT WORK statement is extended when you use it in conjunction with Object Services. Before COMMIT WORK closes the SAP LUW and triggers an update, it calls internal methods of the Persistence Service. These methods bundle the changes made to managed objects of the Persistence Service and pass them to a special update function module using CALL FUNCTION ... IN UPDATE TASK. Thus the Persistence Service works with traditional update methods. The update module is usually registered after any update modules that have already been registered. The update is then triggered and the update task executes the update module in the order in which they were registered.
After the system executes the COMMIT WORK statement, it sets the attributes of each persistent object in the ABAP program to initial. (That is, it calls the IF_OS_STATE~INVALIDATE method).
Local Update
If you want to change managed objects directly, rather than using the update module, you must change the update mode of the implicitly used Transaction Service. That is, the following statements must be executed before the COMMIT WORK statement:
DATA TM type ref to IF_OS_TRANSACTION_MANAGER.
DATA T type ref to IF_OS_TRANSACTION.
TM = CL_OS_SYSTEM=>GET_TRANSACTION_MANAGER( ).
T = TM->GET_CURRENT_TRANSACTION( ).
T->SET_MODE_UPDATE( OSCON_DMODE_DIRECT ).
COMMIT WORK.
To ensure database consistency, the local update is activated internally using SET UPDATE TASK LOCAL. In such cases, the system raises an exception if there are already update modules registered in the update task. You can only register additional classical update modules after setting the mode. They will then also be updated locally.
COMMIT
Basic form
COMMIT WORK.
Addition
... AND WAIT
Effect
Executes a database commit and thus closes a logical processing unit or Logical Unit of Work ( LUW ) (see also Transaction processing ). This means that
all database changes are made irrevocable and cannot be reversed with ROLLBACK WORK and
all database locks are released.
COMMIT WORK also
calls the subroutines specified by PERFORM ... ON COMMIT ,
executes asynchronously any update requests (see CALL FUNCTION ... IN UPDATE TASK ) specified in these subroutines or started just before,
processes the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK ,
cancels all existing locks (see SAP locking concept ) if no update requests exist,
closes all open database cursors (see OPEN CURSOR ) and
resets the time slice counter to 0.
COMMIT WORK belongs to the Open SQL command set.
Return code value
The SY-SUBRC is set to 0.
Notes
All subroutines called with PERFORM ... ON COMMIT are processed in the LUW concluded by the COMMIT WORK command. All V1 update requests specified in CALL FUNCTION ... IN UPDATE TASK are also executed in one LUW . When all V1 update requests have been successfully concluded, the V2 update requests ("update with start delayed") are processed, each in one LUW . Parallel to this, the function modules specified in CALL FUNCTION ... IN BACKGROUND TASK are each executed in one LUW per destination.
COMMIT WORK commands processed within CALL DIALOG processing
- execute a database commit (see above),
- close all open database cursors,
- reset the time slice counter and
- call the function modules specified by CALL FUNCTION IN
BACKGROUND TASK in the CALL DIALOG processing.
However, subroutines and function modules called with PERFORM ... ON COMMIT or CALL FUNCTION ... IN UPDATE TASK in the CALL DIALOG processing are not executed in the calling transaction until a COMMIT WORK occurs.
Since COMMIT WORK closes all open database cursors, any attempt to continue a SELECT loop after a COMMIT WORK results in a runtime error. For the same reason, a FETCH after a COMMIT WORK on the now closed cursors also produces a runtime error. You must therefore ensure that any open cursors are no longer used after the COMMIT WORK .
With batch input and CALL TRANSACTION ... USING , COMMIT WORK successfully concludes the processing.
Addition
... AND WAIT
Effect
The addition ... AND WAIT makes the program wait until the type V1 updates have been completed.
The return code value is set as follows:
SY-SUBRC = 0 The update was successfully performed.
SY-SUBRC <> 0 The update could not be successfully performed.
Note
Runtime errors
COMMIT_IN_PERFORM_ON_COMMIT : COMMIT WORK is not allowed in a FORM callled with PERFORM ... ON COMMIT .
COMMIT_IN_POSTING : COMMIT WORK is not allowed in the update task.
if its useful reward points

COMMIT WORK and WAIT FOR n SECONDS

I am designing a WebDynpro Java application. It makes an update call followed immediately by a display call which should return the data that was just updated. However, it appears that there is some DB latency involved and the data takes a few seconds to update. The application displays old data if the display call is performed too quickly after the update call.
All suggestions I could find point to having a Thread sleep on the Java side for a few seconds or have a WAIT FOR n SECONDS and/or COMMIT WORK AND WAIT statement in the ABAP function module. Neither of these solutions is acceptable in a company-wide application where database latency could vary significantly based on traffic.
I tried all kinds of functions (i.e. BAPI_TRANSACTION_COMMIT) as well as various forms of COMMIT WORK... nothing except a WAIT works correctly. There must be a statement out there that waits for the database write to be complete! How is this solved without picking an arbitrary WAIT time? What am I missing?
Thanks in advance!

You can write the other way.
declare one variable
data : wa_try type i.
wa_try = 10. -> set as 10 ,even you do not get value ,keep on incresing.
after BAPI FM
you can call comitt fm.
after BAPI_TRANSACTION_COMITT
just use simple logic.
do wa_try.
select * from table into table
where record = bapi fm record ( You get in RET2 Message).
if sy-subrc eq 0.
exit.
endif.
Thanks
Seshu

Data lock even after commit work and wait

Hi Experts,
Data is still locked even after commit work and wait step has run, which made me very confusing.
The following are the details:
These steps are in a FOP.
Step1: Change Move-in Date of a move-in document in background after get the new move-date from user.
Step2: Run BAPI_TRANSACTION_COMMIT and pass the wait parameter.
Step3: Bring move-in document transaction to the user for other information changes.
After the user confirms the changes and presses SAVE button, error message shows that the move-in document is still locked. But no other transaction is opened for the specified move-doc changing.
Does any1 have any idea on this? How can I solve this issue?
Thanks in advance and points will be rewarded.
Vincent

Hi,
Normally every BAPI will work on Update task so that the data will be updated once the commit work is done. For the commit work, we will normally call the bapi function module - BAPI_TRANSACTION_COMMIT. It should work.
In your case, just try the below option:
Please call the bapi - BAPI_ACC_DOCUMENT_POST & BAPI_TRANSACTION_COMMIT in a seperate function module and call this function module in your program (just pass the import / export / table parameters accordingly).
For the information, I had once a similar type of issue and it got solved once I did like the above.
Regards,
Selva K.

COMMIT WORK AND WAIT IN BDC

All stock transfer order updates, generating deliveries and picking and post good issues(PGI) are done via BDC processing. That is we have BDC for tcodes: me22, ye02 and vl02.
The issue is the deliveries are not picked and te PGI is completed. we have to use COMMIT WORK AND WAIT statement after every BDC processing.
There is a form ' insert-transaction using tcode '
This form calls BDC_OPEN GROUP, BDCINSERT and BDC_CLOSE_GROUP.
So we write this COMMIT AND WAIT statement after call transaction <tcode>( eg call transaction me22) every time or just after BDC_CLOSE _GROUP in the form.

Hi,
you the call of BDC inside a loop and set the COMMIT WORK AND WAIT for the endloop.
loop ...
bcd-processing.
COMMIT WORK AND WAIT
endloop
Regards
Nicole

Commit work and wait don't work,why

Hi All,
I call BAPI 'BAPI_PO_CREATE1' and create PO, then commit via
commit work and wait.
after creating, query the new PO via
SELECT ebelp pstyp INTO TABLE lt_ebelp
FROM ekpo
WHERE ebeln = p_lv_ebeln.
but no result.
If creating and waiting a moment, it do work.
why, I already used 'commit work and wait' but not 'commit work'.
thanks.
regards.
dou

Okay ,first check whether po number is getting saved or not .
If po is saving then use BAPI_TRANSACTION_COMIITT FM ..
Now check ur select query like : Since wait upto n seconds ( This may not work)
data : n Type i.
n = 10.
write the below code after BAPI_TRANSACTIOn_COMITT.
do n times.
select query
if sy-subrc eq 0.
exit.
endif.
enddo.
still document number is not coming ,testing purpose increate n as 20 and see the results.
Thanks
Seshu

Commit work and wait after bapi execution not working

Hi experts,
I have a requirement from my client that consists on posting 2 documents and then clearing them.
Right now Iu2019m posting the first 2 documents using BAPI_ACC_DOCUMENT_POST and for clearing both documents Iu2019m using Tcode F-51 but sometimes it's giving me an error clearing the documents because after the second bapi run, posting the second document, apparently all went right and a document number it's returned but the database doesnu2019t updated the doc number.
Iu2019m using commit work and wait, and already tried BAPI_TRANSACTION_COMMIT, but it doesnu2019t work sometimes, and the only solution that i found was the Wait up 1 second command , which it's slowing the program execution.
i think the problem it's on the bapi posting execution, due to a lag on the database side, but Iu2019m not sure...
Did anyone already had this problem? Has anyone has a solution for this?
Thanks in advance
Best Regards
João Martins

Hi,
Normally every BAPI will work on Update task so that the data will be updated once the commit work is done. For the commit work, we will normally call the bapi function module - BAPI_TRANSACTION_COMMIT. It should work.
In your case, just try the below option:
Please call the bapi - BAPI_ACC_DOCUMENT_POST & BAPI_TRANSACTION_COMMIT in a seperate function module and call this function module in your program (just pass the import / export / table parameters accordingly).
For the information, I had once a similar type of issue and it got solved once I did like the above.
Regards,
Selva K.

Commit work and wait in release 700 and 701

Hi guys,
it seems that commit work and wait does not behave same in release 700 and 701.
In 701, when using call transaction, upon execution of commit work and wait, it does not anymore proceed to the next lines of codes instead, it exits from the transaction. Hence, other updates are not being executed.
While in 700, it behaves properly.
Please advice.
Thanks!
Moderator message - (Almost) duplicate thread locked
Edited by: Rob Burbank on Jan 25, 2010 10:33 AM

You can use:
CALL TRANSACTION 'ZZZZ' OPTIONS FROM ITAB.
From F1 on CALL TRANSACTION:
... OPTIONS FROM opt
Effect
Allows you to control processing using the values of the componetns of the structure opt, which must have the ABAP Dictionary type CTU_PARAMS. The components have the following meanings:
RACOMMIT
Do not end transaction at COMMIT WORK
Rob

"Commit work and wait" possible with JCA/JRA ?

Similar Messages

Maybe you are looking for