[Urgent] SAP NW RFC SDK Cache ???

[Former Member]

I need to better understand SAP NW RFC SDK Caching, while using the C language connector , client side programming.

I used the bapi BAPI_MDDATASET_CREATE_OBJECT as the function for the following example:

1. It is said that ::RfcGetFunctionDesc(connectionHandle,funcName, pErrorInfo); should return the metadata describing the function and also store it in the Net-weaver RFC runtime on the client side.

Three questions arise from the above:

i) Will it put it in the cache corresponding to the system id present in the connectionHandle ?

ii) Or is it the default cache that is put in ?

iiI) Why would a call to RfcGetCachedFunctionDesc(sysId, funcName,pErrorInfo) not return the handle to the function , I would expect this call to be non null, if it is called after the GetRfcGetFunctionDesc.

2. Should we not call RfcDestroyFunctionDesc(...) at the end to release the runtime memory associated with the client ?

3. If I was to call the RfcDestroyFunctionDesc, why should I get an IllegalState exception. Note: I ensured the function was not in use, and also tried to explicitly remove it from a cache.

Can somebody provide me with a C/C++ code snippet that demonstrates RfcDestroyFunctionDesc to be working ?

Any documents actually explaining caching would be valuable.

[Ulrich_Schmidt · Accepted solution]

Hi Rohit,

1.

(i) According to the documentation, it "supposedly" was put into the cache corresponding to the backend's System ID. But because of a bug, which has only recently been discovered (Feb. 2013), it was in fact put into the hash-map using the key "XYZ\0\0\0\0\0\0", i.e. the SysID plus 6 trailing zeros...

(ii) See (i).

(iii) Because of the above mentioned bug, when calling RfcGetCachedFunctionDesc() with the SysID "XYZ" as key, it would not find anything and return NULL.

(The map compare-function considered "XYZ" != "XYZ\0\0\0\0\0\0".... )

This bug was fixed in note 1818687. So you need the patch level mentioned in that note for the metadata cache to work correctly.

2.

No. This would lead to a double-free, as the NW RFC SDK will also attempt to release the memory, when the cache is cleared later-on.

As written in the documentation, RfcDestroyFunctionDesc() must be used only with metadata that you created yourself using RfcCreateFunctionDesc(), but not with metadata that the runtime created automatically.

3.

Because the runtime noticed, that that object was still "used" in the cache and therefore locked. (This lock is actually a precautionary measure against the danger of the double-free mentioned in 2.)

And removing the function description from the cache via RfcRemoveFunctionDesc() did not work because of the above bug again...

But after you have installed the patch from note 1818687, it should work correctly, so you can just follow this rule:

- if you want to delete your own hard-coded metadata, use RfcDestroyFunctionDesc()

- if you want to delete cached metadata (because you are sure you will no longer need it), use RfcRemoveFunctionDesc(). The runtime will then automatically release all associated memory.

Best Regards, Ulrich