Shared Objects

Session ID: ABAP251

ABAP Shared ObjectsShared Memory Programming Made Easy

Rolf Hammer, SAP AG

Holger Janz, SAP AG

© SAP AG 2004, SAP TechEd / ABAP251 / 3

Learning Objectives

As a result of this workshop, you will be able to:

Understand the concepts of ABAP Shared Objects

Decide when (not) to use ABAP Shared Objects

Define shared memory areas

Store data in shared memory areas

Access data in shared memory areas

Adapt shared memory areas for your needs

Monitor shared memory areas

Advanced Features 1

Motivation

Basic Concepts

Advanced Features 2

What is Shared Memory ?

Data Access without Buffering

Data Access with Buffering by Copy

Data Access with in Place Buffering

Benefits for Application Programming



Different kinds of main memory on an application server

Session MemoryBound to a single user session

Cannot be accessed by a different user session

Guarantees user isolation

Shared Memory (SHM)Shared across session boundaries

No user isolation

Requires access control in a business application context

Application development has longed for buffering data in shared memory for a long time








User XSession

DB



User XSession

DB

Common data

retrieved from DB and

aggregated



User YSession

CommonData

User XSession

CommonData

DB

Common data

retrieved from DB and

aggregated for

each user session

User ZSession

CommonData

CommonData

CommonData








User XSession

DB



User XSession

CommonData

DB

Common data

retrieved from DB



User XSession

DB

Common data

retrieved from DB,

aggregated



User XSession

CommonData

DB

Common data

retrieved from DB,

aggregated,

copied (EXPORT) to SHM

Shared Memory (SHM)

CommonData



User XSession

CommonData

DB

Common data

retrieved from DB,

aggregated,

copied (EXPORT) to SHM,

and copied (IMPORT) toeach user session

Shared Memory (SHM)

CommonData

User YSession

CommonData

User ZSession

CommonData








User XSession

DB

Common data

retrieved from DBdirectly into SHM

Shared Memory (SHM)

CommonData



DB

Common data

retrieved from DBdirectly into SHM,

aggregated in place

Shared Memory (SHM)

CommonData

User XSession



User XSession

DB

Common data

retrieved from DBdirectly into SHM,

aggregated in place

accessed copy-free byother user sessions

Shared Memory (SHM)

CommonData

User YSession

User ZSession








Significant boost in overall performance due to

Reduced memory consumptionData is kept only once in memory

Reduced runtime costsData is aggregated only once

Fast access at main memory speed

In place aggregation for “arbitrary” data structures including strings, internal tables, and references

Reduced maintenance costs due to

Simplified programming model in contrast to solutions based on IMPORT / EXPORT


Applications Using Shared Objects

Workbench navigation

Data is aggregated only once

Ported to ABAP Shared Objects

Saves 3 MB session memory per user

About 100 times faster at first access

Master Data Framework (Financials Basis)

Speed up factor 1000 and more for where used queries

Memory costs reduced to 1/15 per session

Simplified code simplifies maintenance

Advanced Features 1

Motivation

Basic Concepts

Advanced Features 2

Usage Scenarios

Areas and Area Instances

Locking Concept

Creating and Accessing Contents


Usage Scenarios

Main usage scenarios

Shared buffersLow update frequency (e.g. once a day to once per hour) (Very) costly amount of dataMany parallel readers, single writer

Exclusive buffersAccess by a single writer or readerBuffer content is kept across transactions

Coarse granular locking concept

Only a complete buffer can be locked

Rare updates

Readers and writers know each other

Usage Scenarios


Locking Concept




Shared object memory

Part of the shared memory

Customizable by profile parameter

Shared object areas

Organizational units (type)

Defined at design time

Identified by unique name

Shared object area instances

Content stored at runtime

Unique name within the area

Single-instance area addressed by default name

Shared Memory

Area Area

Instance

Instance

Instance

Shared Object Memory


Area Instances and Objects

Objects are reachable via references

Area instances have a root object

All objects must be reachable from the root object

Area instances are self-contained, i.e. no outgoing references to

User session memory

Other shared objects area instances

Inner references are allowed

Instance

Root


Design Time Support

Instance

Area: cl_cl_mmy_areay_area

Root: cl_my_rootcl_my_root

Areas are defined at design time with the shared objects area manager (transaction SHMA)

Area name corresponds to aclass to be generated (e.g. cl_my_area)

Name of root class must be specified (e.g. cl_my_root)


Shared Memory Enabling of a Root Class

Common class defined with class builder (transaction SE24)

Checkbox ‘Shared Memory Enabled’ active


Definition of a Shared Memory Area

Special class defined with the shared objects area manager (transaction SHMA)

Root class must be specified


Abstract Area Class

Transaction SHMA generates for each area a class which inherits from the abstract class cl_shm_area

cl_shm_area

cl_my_area1 cl_my_area2 cl_my_area3

Usage Scenarios


Locking Concept



Locking Concept

Coarse granular locking concept

Lock kinds: read, write, and update

Only complete area instances can be locked

Write/Update locks are exclusive

In general immediate response to locking requests (success or exception)

Only one read lock per internal session on the same area instance

Default lock duration until end of current internal session


Attaching to an Area Instance

Instance

Root

User YSession

Handle

User XSession

Handle Handle

Provides access to a shared objects area instance

Creates handle object

Sets appropriate lock

Makes reference to rootobject available

Methods

attach_for_readattach_for_writeattach_for_update


data:...myShmHandle type ref to cl_my_area, myRoot type ref to cl_my_root.

myShmHandle = cl_my_area=>attach_for_write( ).

Open default instance forwrite

Example: Write Access


Detaching from an Area Instance

Instance

Root

User YSession

Handle

User XSession

Handle Handle

Cancels access to a shared objects area instance

Invalidates handle object

Releases lock

Makes reference to rootobject unavailable

Changes must be committed or rolled back

Methods

detachdetach_commitdetach_rollback




...

if ...myShmHandle->detach_commit( ).

else.myShmHandle->detach_rollback( ).

endif.

Example: Detach from Write Access

Rollback changes

Commit changes

Usage Scenarios


Locking Concept



Creating Data Objects

CREATE OBJECT … AREA HANDLE hdl.Creates instance of a class

Only instance attributes are created

Class attributes exist only once per session

Class must be ‘shared memory enabled’

Class builder property flag

special addition SHARED MEMORY ENABLEDat class definition section

CREATE DATA … AREA HANDLE hdl.Creates instance of a data type

All data types can be instantiated (future release)




create object myRoot area handle myShmHandle. myRoot->name = 'My first area instance'. append wa to myRoot->itab....if ...

myShmHandle->set_root( myRoot ).myShmHandle->detach_commit( ).

else.myShmHandle->detach_rollback( ).

endif.

Example: Filling Contents

Create arbitrary (data)objects in shared memory

Set root object and commit changes


Accessing Data Objects

All objects are accessible via root object

Handle provides reference to root object

Example:

x = myShmHandle->root->myObject->myAttribute.


data:myShmHandle type ref to cl_my_area.

myShmHandle = cl_my_area=>attach_for_read( ).

read table myShmHandle->root->itabinto wa index i.

...

myShmHandle->detach( ).

Open defaultinstance for read

Example: Accessing Contents

Access rootobject components

Release lock


Shared Objects Area Monitor

Shared objects area monitor (transaction SHMM)

Overview on areas, instances, and locks

Content browser


Demo

Demo 1


Exercise

Exercise 1

Advanced Features 2

Basic Concepts

Advanced Features 1

Multi Attach

Preloading

Versioning

Client Dependency


Multi Attach

Method MULTI_ATTACH must be used to attach to more than one area within one internal session

Precluding of dead lock situations

How to use MULTI_ATTACH

Pass an internal table with all needed area description

Specify ignoring errors, if needed

Specify wait time, if needed

Handles for every attached area or exception object will be returned


data:attach_tab type shm_attach_tab,attach_wa like line of attach_tab,error_flag type abap_bool.

attach_wa-area_name = 'ZCL_MY_AREA_1'.attach_wa-inst_name = cl_shm_area=>default_instance.attach_wa-lock_kind = cl_shm_area=>lock_kind_read.insert attach_wa into table attach_tab.

attach_wa-area_name = 'ZCL_MY_AREA_2'.attach_wa-inst_name = cl_shm_area=>default_instance.attach_wa-lock_kind = cl_shm_area=>lock_kind_write.insert attach_wa into table attach_tab.

cl_shm_area=>multi_attach(importing error_flag = error_flagchanging attach_tab = attach_tab ).

Multi Attach Example

Multi Attach

Preloading

Versioning

Client Dependency


Preloading

Automatic preloading (buffer warm-up) for area instances can be specified at design time

Requires the specification of a loader class implementing the interface if_shm_build_instance

The automatically started loader runs asynchronously in aseparate session (of the same user) to avoid side effects on the caller

Possible options for the preload starting point

Due to a read request if no active version is available

Due to invalidation, i.e. if the active version becomes out of date or expires (includes above case)


Preloading

Preloading is specified at design time using transaction SHMA


data:hdl type ref to zcl_my_area,excp type ref to cx_shm_no_active_version.

try.hdl = zcl_my_area=>attach_for_read( ).catch cx_shm_no_active_version into excp.if excp->textid <>

cx_shm_no_active_version=>build_started andexcp->textid <>

cx_shm_no_active_version=>build_not_finished.raise exception excp.

endif.wait up to 1 seconds.hdl = zcl_my_area=>attach_for_read( ).

endtry.

Preloading Example

Multi Attach

Preloading

Versioning

Client Dependency


Versioning Example

Instance

Version: active

Reader1


Versioning Example

Instance

Version: active Version: under construction

WriterReader1


Versioning Example

Instance

Version: active Version: under construction

WriterReader1

Reader2


Versioning Example

Instance

Version: out of date

Version: active

Reader1Reader2


Versioning Example

Instance


Version: active

Reader1Reader2 Reader3


Versioning Example

Instance


Version: active

Reader1Reader3


Versioning Example

Instance

Version: expired

Version: active

Reader3


Versioning Example

Instance

Version: active

Reader3


States of Versions

The 4 States

1. Under construction (0..1): As long as a version is being changed

2. Active (0..1): Last committed version used for further read attaches

3. Out of date (0..n): Version with still attached readers, no further read attaches possible

4. Expired (0..n): Out of date and no more readers; will be automatically garbage collected

Version

under construction

Version

active

Version

out of date

Version

expired


Versioning Concept

Versioning is defined at design time

Maximum number of versions can be specified at design time

Versioning guarantees that read attaches can be satisfied in general

Strictly speaking a version is an area instance version


Versioning

Versioning is specified at design time using transaction SHMA

Multi Attach

Preloading

Versioning

Client Dependency


Client Dependency

Client dependency is specified at design time

Needed if area instances shall be client aware, i.e. if different clients require different instances

Analogy to database client handling

Client is part of the area instance name

Optional client parameter for most area methods (default: current client, only possible without preloading)

Predefined constant to address all clients


Client Dependency

Client dependency is specified at design time using transaction SHMA


Demo

Demo 2


Exercise

Exercise 2

Advanced Features 2

Basic concepts

Advanced Features 1

Transactional Areas and Propagation

Displacement

Memory Limits

Binding


Transactional Areas Motivation

Instance

Area

Database

Version1

Database changes



Database

Database changes

Area instance depending on database changes Instance

Area

Version1

Version2



Database

Database changes

Area instance depending on database changes

Area commit, version 1 gets out of date

Instance

Area

Version1

Version2



Database

Database changes


Area commit, version 1 getsout of date and expires

Instance

Area

Version2



Database

Database changes


Area commit, version 1 getsout of date and expires

Database rollback inconsistency in area instance

Instance

Area

Version2

???


Transactional Areas Solution

Transactional behavior is specified at design time

Versions finished with detach_commit becomes active with the next database commit

Read attaches before the next database commit will be routed to still active version

Example: Area with versioning

v1 activev2 under construction

v1 out of datev2 active

DB commitdetach_commit

v1 activev2 pending

Read v2

read v1read v1

write v2


Propagation Motivation

Database

Instances reside on Application Server instances

Instance

AppServer 1

Version 1

Instance

AppServer 2

Version 1

Instance

AppServer 3

Version 1



Database


Instance changes

Instance

AppServer 1

Version 1

Version 2

Instance

AppServer 2

Version 1

Instance

AppServer 3

Version 1



Database


Instance changes do not affect other servers

Instance

AppServer 1

Version 1

Version 2

Instance

AppServer 2

Version 1

Instance

AppServer 3

Version 1



Database


Instance changes do not affect other servers

Instance mismatch on other application servers

Instance

AppServer 1

Version 2

Instance

AppServer 2

Version 1

???

Instance

AppServer 3

Version 1

???


Propagation Solution

Database

Instance changes are not propagated to other servers, only an invalidation record is sent

Instance

AppServer 1

Version 1

Version 2

Instance

AppServer 2

version1???

Instance

AppServer 3

version1???

Version 1 Version 1


Propagation Solution

Database

Instance changes are not propagated to other servers, only an invalidation record is sent

New versions are created at next read request via automatic preloading

Instance

AppServer 1

Version 2

Instance

AppServer 2

Version 1

Version 2

Instance

AppServer 3

Version 1

Version 2


Propagation

Propagation is automatically specified at design time for all transactional areas

Needed for area instances that shall be kept in sync on several application servers

Propagation is only possible for transactional areasTechnical reason: sync records via database

Conceptual reason: In general propagation will be needed, if area contents depend on database contents

Pull modelReceiving a sync record lets the active version becomeout of dateRebuild is not forced (push model) but depends on preloading options

Propagation only means a system wide invalidation of areas.Automatic preloading is used to create updated version.



Transactional Areas are specified at design time using transaction SHMA

Propagation is done via invalidation using the PROPAGATE methods


data:root type ref to zcl_my_area_root,hdl type ref to zcl_my_area.

hdl = zcl_my_area=>attach_for_write( ).create object root area handle hdl.hdl->set_root( root ).hdl->detach_commit( ).

zcl_my_area=>propagate_instance( ).

commit work.

Transactional Areas and Propagation Example


Displacement

Memory Limits

Binding


Displacement

Displacement means that an area instance version with noactive readers can be pushed out of shared memory

Dynamic area property specified at design time

Recommended on 32-bit systems only

The following displacement modes can be specified

Simple displacement without saving area contents

Displacement by serialization to disk (future SAP NetWeaverrelease)

Every object must be serializable (tag interface if_serializable_object)Deserialization at the next read request


Displacement

Displacement is specified at design time using transaction SHMA


Displacement

Memory Limits

Binding

Lifetime


Memory Limits

Memory limits are defined at design time for

one area instance

all instances of one area (future SAP NetWeaver release)

Used to prevent applications to run wild in shared memory.

Gives tools and administrator an idea how much shared memory is needed for a certain application.


Memory Limits

Memory Limits is specified at design time using transaction SHMA

Lifetime


Displacement

Memory Limits


Lifetime

Lifetime is defined at design time

Automatic invalidation or preloading after lifetime

One out of three kinds of lifetime can be specified

Up to expiry (invalidation time), invalidation

Up to update (refresh time), preloading

Without read access (idle time), invalidation

Used to free unused or to refresh to contents of sharedmemory


Lifetime

Lifetime is specified at design time using transaction SHMA


Demo

Demo 3


Exercise

Exercise 3


Encapsulation

Reader

Reader

Session Area

Instance1

Instance2

Instance3Reader

Writer

Avoid direct access to shared memory area instances


Reader

Reader

Reader

Reader

Session

Broker

Area

Instance1

Instance2

Instance3

Instead, it is recommended to communicate with an area via a broker class that encapsulates

Broker

Area initialization

Area access

Lock administration

Authority checks


Area Properties - Overview

The following properties can be specified at design time

Versioning

Preloading

Transactional

Propagation

Client dependency

Displacement

Memory limits

Lifetime


Additional Features

Conceptual

Error handling via exceptions

Query methods for handle state

Special roll handle to address roll area

Technical

Consistency check for types used at area build-up and attach time

Garbage collection for area instances

Copy-on-write becomes copy-on-detach for internal tables and strings


Summary

ABAP Shared Objects is used to share common databetween different session

Coarse granular locking concept supports shared buffer or exclusive buffer

Versioning is used to implement high available services

Transactional areas are used to synchronize shared object instances with database

Propagation is used to synchronize shared object instances on different application server


Further Information

Public Web:www.sap.com

SAP Developer Network: www.sdn.sap.com

SAP Customer Services Network: www.sap.com/services/

Related Workshops/Lectures at SAP TechEd 2004ABAP201, Best of ABAP - The Ultimate ABAP 6.40 Feature Show , 2h Lect.

ABAP351, Advanced and Generic Programming in ABAP, 4h Hands-on

ABAP253, ABAP Troubleshooting, 4h Hands-on

ABAP151, ABAP Objects for Java Developers, 2h Hands-on

ABAP255, New ABAP Debugger and Memory Inspector , 2h Hands-on

Related SAP Education Training Opportunitieshttp://www.sap.com/education/


SAP Developer Network

Look for SAP TechEd ’04 presentations and videos on the SAP Developer Network.

Coming in December.

http://www.sdn.sap.com/


Q&A

Questions?


Please complete your session evaluation.

Be courteous — deposit your trash, and do not take the handouts for the following session.

Feedback

Thank You !


No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, and Informix are trademarks or registered trademarks of IBM Corporation in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Copyright 2004 SAP AG. All Rights Reserved

Documents

Shared Objects