2014 Feb 04 11:20 AM
Hello,
we configured bgRFC in our system. We use it to launch a external webservice.
In SBGRFCMON we almost always get an error: "A database commit was blocked by the application".
In SM12 two locks appear : one on BGRFC_I_SERVER_REGISTRATION and one on BGRFC_O_SERVER_REGISTRATION.
In ST22 we have the following dump:
Client.............. 200
User................ "U0000657"
Transaction......... " "
Call Program........."CL_BGRFC_DS_EXEC_INBOUND======CP"
Function Module..... "BGRFC_DEST_SHIP"
Call Destination.... "d11_D11_00"
Source Server....... "d11_D11_00"
Termination occurred in the ABAP program "SAPLHTTP_RUNTIME" - in
"HTTP_READ_SC".
The main program was "SAPMSSY1 ".
In the source code you have the termination point in line 22
of the (Include) program "LHTTP_RUNTIMEU07".
* all obsolete with new system-call interface!!!
data: fields_dummy type tihttpnvp,
cookies_dummy type tihttpcki,
data_dummy type xstring,
content_type_dummy type string,
content_name_dummy type string,
state_dummy type i,
parse_body_dummy type i,
rc type i.
connection-ecode = 101. "unknown mode
system-call plugin
id 'HTTP' value 'Receive' "#EC NOTEXT
id 'Name' value connection-name "#EC NOTEXT
id 'EntityFields' table fields_dummy[] "#EC NOTEXT
id 'EntityCookies' table cookies_dummy[] "#EC NOTEXT
id 'EntityContentType' value content_type_dummy "#EC NOTEXT
id 'EntityContentName' value content_name_dummy "#EC NOTEXT
id 'EntityState' value state_dummy "#EC NOTEXT
id 'EntityParseBody' value parse_body_dummy "#EC NOTEXT
id 'EntityBody' value data_dummy "#EC NOTEXT
* id 'EntityHeader' VALUE header.
id 'MessageIn' value c_msg "#EC NOTEXT
id 'ConnectionId' value connection_id "#EC NOTEXT
id 'RC' value rc. "#EC NOTEXT
When we launch the same function (with the webservice) without using bgRFC - synchronous - everything works fine.
Anyone any idea where we might look for a solution for this problem?
Thanks.
Kris
2014 Feb 12 8:18 AM
The bgRFC has a commit trap, as commits within bgRFC unit processing are generally not recommended. In case a commit is necessary (as e.g. the implicit DB commit caused by an HTTP call within WS processing), there is an option to switch off the bgRFC commit trap for a specific bgRFC unit. This is exposed via interface IF_BGRFC_UNIT, and e.g. is used by WS for the reason explained above.
So if the bgRFC commit trap is responsible for the dumps, the application has the option either to avoid the commit or switch off the commit trap.
So this is the statement that solves the problem:
gr_unit->if_bgrfc_unit~disable_commit_checks( ).
Regards.
2014 Feb 12 8:18 AM
The bgRFC has a commit trap, as commits within bgRFC unit processing are generally not recommended. In case a commit is necessary (as e.g. the implicit DB commit caused by an HTTP call within WS processing), there is an option to switch off the bgRFC commit trap for a specific bgRFC unit. This is exposed via interface IF_BGRFC_UNIT, and e.g. is used by WS for the reason explained above.
So if the bgRFC commit trap is responsible for the dumps, the application has the option either to avoid the commit or switch off the commit trap.
So this is the statement that solves the problem:
gr_unit->if_bgrfc_unit~disable_commit_checks( ).
Regards.
2019 May 03 11:05 AM
2022 Oct 24 12:37 AM
Hi SN SANTOSH P,
Could u plz let us know how u resolved the dump "A database commit was blocked by the application".where is the option for switch off the commit trap.
Thank You.