Hang on to your hats! (shared buffer in multi-WAS/multi-update process env)

[Former Member]

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]

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.

[former_member181923]

Thomas -

Thanks very much for taking the time. I had actually read that entire section of the on-line help but figured that the situation couldn't really be that bad - that there was a special syntax that could be used to name a truly shared buffer.

It looks like I'm going have to slow the app down considerably by using custom Z work-tables. I guess if we force-cache them, it might yield about the same performance.

Again - thanks very much. I can't believe SAP has let a hole this big persist in multi-WAS environments.

Regards

djh

[matt]

I found this thread as we are facing the same problem.

The solution we've come up with is to encapsulate the EXPORT and IMPORT in an RFC enabled function module. When we want to export or import, we call this fm with DESTINATION appserv - where appserv is a nominated application server.

This means that the application, no matter where it runs, uses the shared memory of just one server.

matt