Hang on to your hats! (shared buffer in multi-WAS/multi-update process env)
At my curreent client, we have some custom code which involves a <b><i><b>dialog</b></i></b> <i><b>process</b></i> exit in XQSM and an<i><b> update</b></i> process exit in XMBC.
When developing this code, the question arose as to how to coordinate data between the dialog process exit and the update process exit.
And following the advice of Rich H and others here at SDN, we use <i><b>shared buffer</b></i> instead of usual memory. For example:
In the XSQM dialog process exit, we do this:
CONCATENATE sy-uname sy-datum context_id INTO v_memkey. EXPORT gt_outtab TO SHARED BUFFER indx(st) ID v_memkey.
And in the XMBC update process exit, we do this:
CONCATENATE sy-uname sy-datum context_id INTO v_memkey. IMPORT gt_outtab FROM SHARED BUFFER indx(st) ID v_memkey.
This has been working fine in our DEV and QA systems - tested over and over again for months before we moved the code to PROD.
Now in PROD, we get occasional problems.
So I spoke to an SAP Basis consultant who happens to be on-site and he told me there's a critical difference between the DEV and QA systems here and the PROD system here.
The DEV system has only one WAS running multiple update processes.
The QA system has only one WAS running multiple update processes.
But the PROD system has four WAS's each running multiple update processes.
So, he (the SAP Basis consultant) told me to ask you all whether it's possible that the <i><b>indx(st) buffer</b></i> mentioned in the above code is <i><b>not the same across the all four WAS's.</b></i>
If it's not, then we know immediately why we are having problems in PROD but not in DEV or QA.
And then the second question is: <i><b>how do we tell the system to use a shared buffer that is common to all four PROD WAS's.</b></i>
Any takers on this one? (No guesses, please!!!)
Thanks for thinkin about it.
Thomas Jung replied
You have but to check the online help for part of the answer to your question:
<i>When specifying SHARED MEMORY or SHARED BUFFER, the data cluster is stored in cross-transaction application buffers of the shared memory on the application server, to which all programs of the same application server have access.</i>
So that shared memory or shared buffer that you are using is specific to the particular application server. Now the Update Workprocess and the Dialog Workprocess that spawned it do not necessarily have to be on the same application server. This is part of the load balancing and scalability of the ABAP application server. Normally this isn't an issue because you only use the shared memory or shared buffer between calls within the dialog work process stack. However as soon as you want to cross over into the Update workprocess they really can't be used reliably as you found out.
You can try dong the expor to DATABASE instead, but I can't say for sure that will work in your case either. The export to DATABASE doesn't perform its storage until the next Commit Work which since you are dealing with an Update process might be too late. You would have to test to see if this helps out.