Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Showing results for 
Search instead for 
Did you mean: 

Shared Objects issue

Active Participant
0 Kudos

Hi guys,

I'm experiencing problems using Shared Objects.

My goal was to save in a Shared Memory Area an internal table (defined as an instance attribute of the root class) and then fetch that in another program to update those records in the database.

Unfortunately, the first running program must update the area at every cycle, and that's the problem.

Area is declared with "With versioning" attribute checked.

The generation of the area is done like that:

lr_area = zcl_shm_manage_quota=>attach_for_update( 'MANAGE_QUOTA' ).
CATCH .... 
"catching all the cx_shm* exceptions and if something is messed up, I call up the 
"attach_for_write method
lr_area = zcl_shm_manage_quota=>attach_for_write( 'MANAGE_QUOTA' ).
"this is called only in area generation, because if I attach for update, the root
"object is already set up
lr_area->set_root( lr_root ).

In an another form, I set up the internal table, using an ad-hoc defined method in the root class, called set_data:

lr_area->root->set_data( struc ).

And that's done in every cycle of the running program.

The second program is attaching for read, by using the attach_for_read method, and reads the internal table attribute of the root class, updating its content into the database.

After the update, the area is invalidated and cleared, by this:

lr_area->free_area( ).

So, at first time, the attach_for_update method fails, and the CATCH structure resolves all by create a new area (or version) by attaching for write. From the second time and over, the attach_for_update method should be ok.

But sometimes, and apparently in a totally randomic behaviour, the attach_for_update method fails again and the CATCH structure calls attach_for_write method. And this will end in a Short Dump, saying "SHM Change Lock active".

Have anyone an idea?

How should the area generation be made to have all this stuff work out correctly?

Thanks in advance,



Developer Advocate
Developer Advocate
0 Kudos

Not sure about the free area method, are you using the detach_commit method after the update?


Rich Heilman

0 Kudos

Hi Rich,

yes, after the update, if no exception is triggered, I detach from the area using detach_commit (if an error occurs, i rollback changes using detach_rollback).

As a consequence of a detach, I must re-attach using attach_for_update everey time I need to made changes to the content of the area.