How to combine Shared Memory Objects with Persistency?

[Former Member]

Hi,

I have shared memory objects, that are instantiated from the database.

But I can not save their state back to the database.

I always receive the exception CX_SHM_EXTERNAL_REFERENCE on the persistent objects.

The persistency layer only works one way ...

I tried everything from the wonderfull book "Next Generation ABAP Development".

How can I solve this?

Where can I find some good documentation on this subject?

thanks,

Jan

[narin_nandivada3]

Hi Jan,

Please check these links

[Shared Objects|http://help.sap.com/saphelp_nw2004s/helpdata/en/14/dafc3e9d3b6927e10000000a114084/frameset.htm]

[PDF for Shared memory programming|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/900e3d9d-559e-2910-9dae-b132157a220f]

[Shared objects in ABAP|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/c322c690-0201-0010-fb86-811c52b0acc2]

[Blog by Thomas Jung in ABAP Shared Memory|https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/1070] [original link is broken] [original link is broken] [original link is broken];

Hope this would be helpful to solve your issue.

Good luck

Narin

[Former Member]

Hi Narin,

Thanks for the links.

The last one is usefull for me, it gives some info to more understand the subject.

But I still have no solution for the problem and I begin to think that it's not possible.

If I can instantiate SHMO from the database, I would also like to save their changed state back into the database.

But all documentation on saving SHMO 's stops at the Shared Memory level.

Maybe it's a question for Rich Heilman or Thomas Jung.

regards,

Jan

[narin_nandivada3]

Hi Jan.

At the end of the Thomas Jung blog leave a comment.. so that he would give you suggestion.

Regards

Narin

[GrahamRobbo]

Hi Jan,

While you await Thomas' advice here are my thoughts - most of which I am sure you have figured out yourself.

Your problem is that your are trying to create or use an outbound reference in your shared object. Shared objects need to be totally self-contained.

So your data persistence layer needs to be implemented, instantiated, and otherwise controlled from inside the shared object.

It is possible that you simply cannot do this with a persistent object - I haven't tried it - but as you mentioned in this tread that you "instantiate SHMO from the database" it may be that you are breaking this rule.

Perhaps you need to double-check that your shared object is fully self-contained?

Cheers

Graham Robbo

[Former Member]

Hi Graham,

Thanks for your reaction.

This is exactly what happens. I have broken a loosely defined rule. The result of doing before thinking!

In the meantime I have tried other options, but now I am convinced that SHMO is only a fast read-only solution.

The self-contained version works just fine and I will continue in that direction.

There is at least some misleading info on the subject SHM.

Good candidates for SHM are datasets that are frequently read but have only few updates.

The documentation should better explain that it's a read-only solution and that the updates should always go in the business objects.

But I am on the right track now, I think.

regards,

Jan

[Former Member]

For me SHM is a read-only solution for fast data access. Books and other documentation gave the impression that it can also working with persistent data. It can not keep references to external objects. But it's great, as it is ...

[GrahamRobbo]

Hi Jan,

it is certainly true that shared objects are positioned primarily for read access. The locking concept in shared objects provides for only one writer or updater at a time. A typical use case for shared objects would be a product catalogue that provides high-speed access to catalogue data that rarely changes.

I haven't got time to have a play at the moment, but I don't immediately see why you couldn't implement the persistency layer using Persistent Objects inside a shared object. You would need to ensure you instantiate and execute the persistent object from inside the shared object and that you only called the persistent objects when the client has connected for update or write.

SAP doco says...

It is recommended that application programs do not access the shared objects memory directly, but that (read) accesses to the shared objects are instead wrapped in a wrapping class, whose (GET) methods are accessed by the individual programs. The area constructor class can be used as the wrapping class, for example.
Wrapping has the following advantages:
·        Central administration of an area in the shared memory
·        An application program does not need to worry about area handles and locks.
·        Central administration of locks
·        Option to implement central authorization checks

I guess this wrapper class might be the sort of place you could implement persistence if you had to do it.

Cheers

Graham Robbo