‎2011 Oct 12 8:24 AM
Hi there
We're using Shared Memory Areas to share data between an on-line transaction and a background program. The on-line transaction collects the data, creates the Shared Memory Area and submits a background job to process it. So, after the detach_commit, it performs submit program via job_name xxxx number nnnn.
It works OK in our dev and quality systems, but does not work in our production system. The memory area is created OK, but the job cannot access it. In the background program, we get the message:
"The read lock on the instance 'ZNNNNNNN' in the client '100' of the shared objects memory area 'ZCL_XXX' cannot be set, since there is no active version of this area instance. However, the area constructor for the automatic construction of the area instance was started."
On the SMA side, we've tried seemingly every combination, even "propagate_instance".
The job seems to be running on the same application server as the SMA.
Any ideas about what we're doing wrong, anyone?
Thanks
Ged
‎2011 Oct 12 8:46 AM
Hi ,
if possible change it to "Export/Import to Database ID".
regards
Prabhu
‎2011 Oct 12 8:46 AM
Hi ,
if possible change it to "Export/Import to Database ID".
regards
Prabhu
‎2011 Oct 12 9:33 AM
Hi Prabhu
Yes, thanks for the suggestion. We had that technique lined up as a fall-back scenario, but we would really like a solution to our SMA problem.
Cheers
Ged
‎2012 Sep 13 8:04 AM
Hello Ged,
Please remember that SHM is accessible across one App Server(AS) only.
If your SAP landscape has multiple AS's then it might pose a problem. When you're scheduling the background job, i guess that the Bgd work process is started in a different AS(load balancing ) and hence SHM is no accessible.
If this is the case, then you've no other option but to store the data persistently in DB clusters viz., INDX-type tables (EXPORT TO/IMPORT FROM DATABASE).
BR,
Suhas
Message was edited by: Suhas Saha
‎2012 Sep 13 9:38 AM
Hi Suhas
Almost certainly, you are correct. I seem to remember (it was some time ago now) checking out the AS where the background jobs were running and finding that they were the same but I suppose I was mistaken.
In any case, I think the design of the original application was wrong in trying use SHM in an online/background context. Clearly SHM is most useful in a purely online context where rapid access to complex data objects held in AS memory is needed, without the overhead of additional DB access and processing.
Thanks for your answer.
Regards
Ged
‎2012 Sep 12 9:47 PM
Hi, maybe the problem is that your system have more than one applications. Can you try with method PROPAGATE_INSTANCE?
regards
‎2012 Sep 13 9:23 AM