SAP Shared Memory Presentation

Session ID: ABAP251 ABAP Shared Objects
Shared Memory Programming Made Easy
Rolf Hammer, SAP AG Holger Janz, SAP AG
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
SAP AG 2004, SAP TechEd / ABAP251 / 3
Motivation Basic Concepts Advanced Features 1 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
What is Shared Memory ?
Different kinds of main memory on an application server

Session Memory
Bound Cannot
to a single user session be accessed by a different user session user isolation
Guarantees
Shared Memory (SHM)

Shared No
across session boundaries access control in a business application context
user isolation
Requires
Application development has longed for buffering data in shared memory for a long time
Data Access without Buffering
DB
User X Session
Data Access without Buffering Common data

retrieved from DB and DB aggregated
User X Session
Data Access without Buffering Common data

retrieved from DB and DB aggregated for each user session
Common Data User X Session
Common Data User Y Session
Common Data User Z Session
Data Access with Buffering by Copy
DB
User X Session
Data Access with Buffering by Copy Common data

retrieved from DB DB
Common Data
User X Session
Data Access with Buffering by Copy Common data

retrieved from DB, DB aggregated
User X Session

Shared Memory (SHM) DB Common Data
Common data
retrieved from DB, aggregated, copied (EXPORT) to SHM

Common data
retrieved from DB, aggregated, copied (EXPORT) to SHM, and copied (IMPORT) to each user session
Common Data User Y Session
Common Data User Z Session
Data Access with in Place Buffering

Common data
retrieved from DB directly into SHM
User X Session

Common data
retrieved from DB directly into SHM, aggregated in place
User X Session

Common data
retrieved from DB directly into SHM, aggregated in place accessed copy-free by other user sessions
User X Session
User Y Session
User Z Session
Benefits for Application Programming
Significant boost in overall performance due to

Reduced memory consumption
Data
is kept only once in memory is aggregated only once
Reduced runtime costs

Data 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
Motivation Basic Concepts Advanced Features 1 Advanced Features 2
Usage Scenarios Areas and Area Instances Locking Concept Creating and Accessing Contents
Usage Scenarios
Main usage scenarios

Shared buffers
Low
update frequency (e.g. once a day to once per hour) (Very) costly amount of data Many parallel readers, single writer
Exclusive buffers
Access by a single writer or reader Buffer content is kept across transactions
Coarse granular locking concept

Only a complete buffer can be locked Rare updates Readers and writers know each other
Areas and Area Instances Shared object memory

Part of the shared memory Customizable by profile parameter Shared Memory Shared Object Memory Area I n s t a n c e I n s t a n c e Area I n s t a n c e
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
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 selfcontained, i.e. no outgoing references to
User session memory Other shared objects area instances
Instance Root
Inner references are allowed
Design Time Support Areas are defined at design time with the shared objects area manager (transaction SHMA)
Area name corresponds to a class to be generated (e.g. cl_my_area) Name of root class must be specified (e.g. cl_my_root)
Area:
cl_my_area
Instance Root: 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
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 Provides access to a shared objects area instance Creates handle object Sets appropriate lock Makes reference to root object available Methods attach_for_read attach_for_write attach_for_update
User X Session User Y Session Handle Handle Instance Root
Handle
Example: Write Access

data: ... myShmHandle type ref to cl_my_area, myRoot type ref to cl_my_root.
Open default instance for write
myShmHandle = cl_my_area=>attach_for_write( ).
Detaching from an Area Instance Cancels access to a shared objects area instance Invalidates handle object Releases lock Makes reference to root object unavailable Changes must be committed or rolled back Methods detach detach_commit detach_rollback
Instance Root
Handle Handle User X Session
Handle User Y Session
Example: Detach from Write Access

data: ... myShmHandle type ref to cl_my_area, myRoot type ref to cl_my_root. myShmHandle = cl_my_area=>attach_for_write( ). ...
if ... myShmHandle->detach_commit( ). else. myShmHandle->detach_rollback( ). endif.

Commit changes Rollback changes
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 ENABLED at class definition section
CREATE DATA AREA HANDLE hdl.

Creates instance of a data type All data types can be instantiated (future release)
Example: Filling Contents

data: ... myShmHandle type ref to cl_my_area, myRoot type ref to cl_my_root. myShmHandle = cl_my_area=>attach_for_write( ). create object myRoot area handle myShmHandle. myRoot->name = 'My first area instance'. append wa to myRoot->itab. Create arbitrary (data) ... objects in shared memory if ... myShmHandle->set_root( myRoot ). Set root object and myShmHandle->detach_commit( ). commit changes else. myShmHandle->detach_rollback( ). endif.
Accessing Data Objects
All objects are accessible via root object Handle provides reference to root object Example:
x = myShmHandle->root->myObject->myAttribute.
Example: Accessing Contents

data: myShmHandle type ref to cl_my_area. Open default instance for read
myShmHandle = cl_my_area=>attach_for_read( ). read table myShmHandle->root->itab into wa index i. ... myShmHandle->detach( ).
Access root object 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
Basic Concepts Advanced Features 1 Advanced Features 2
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
Multi Attach Example

data: attach_tab type shm_attach_tab, attach_wa like line of attach_tab, error_flag type abap_bool. attach_wa-area_name = attach_wa-inst_name = attach_wa-lock_kind = insert attach_wa into attach_wa-area_name = attach_wa-inst_name = attach_wa-lock_kind = insert attach_wa into 'ZCL_MY_AREA_1'. cl_shm_area=>default_instance. cl_shm_area=>lock_kind_read. table attach_tab. 'ZCL_MY_AREA_2'. cl_shm_area=>default_instance. cl_shm_area=>lock_kind_write. table attach_tab.
cl_shm_area=>multi_attach( importing error_flag = error_flag changing attach_tab = attach_tab ).

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 a separate 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
Preloading Example
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 and excp->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.
Versioning Example
Instance Version: active
Reader1
Versioning Example
Instance Version: active Version: under construction
Reader1
Writer
Versioning Example
Instance Version: active Version: under construction
Reader1 Reader2
Writer
Versioning Example
Instance Version: out of date Version: active
Reader1 Reader2
Versioning Example
Reader1 Reader2
Reader3
Versioning Example
Reader1
Reader3
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
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
Basic concepts Advanced Features 1 Advanced Features 2
Transactional Areas and Propagation Displacement Memory Limits Binding
Transactional Areas Motivation

Database changes
Area Instance Version 1
Database

Database changes Area instance depending on database changes
Version 2
Database

Database changes Area instance depending on database changes Area commit, version 1 gets out of date
Version 2
Database

Database changes Area instance depending on database changes Area commit, version 1 gets out of date and expires Version 2
Area Instance
Database

Database changes Area instance depending on database changes Area commit, version 1 gets out of date and expires Database rollback inconsistency in area instance Version 2 ???
Area Instance
Database
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 active v2 under construction read v1 Read v2 write v2 detach_commit
v1 active v2 pending read v1
v1 out of date v2 active
DB commit
Propagation Motivation
Instances reside on Application Server instances
Database
AppServer 1 Instance Version 1
Instances reside on Application Server instances Instance changes Database
AppServer 1 Instance Version 1 Version 2
Instances reside on Application Server instances Instance changes do not affect other servers Database
Instances reside on Application Server instances Instance changes do not affect other servers Instance mismatch on other application servers Database
AppServer 1 Instance
AppServer 3 Instance Version 1 ???
Version 2
???
Propagation Solution
Instance changes are not propagated to other servers, only an invalidation record is sent
Database
version1 1 Version ???
version1 1 Version ???
Propagation Solution
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 Database
Version 2
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 areas

Technical reason: sync records via database Conceptual reason: In general propagation will be needed, if area contents depend on database contents Pull model Receiving a sync record lets the active version become out of date Rebuild 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 and Propagation
Transactional Areas are specified at design time using transaction SHMA Propagation is done via invalidation using the PROPAGATE methods
Transactional Areas and Propagation Example

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 Displacement Memory Limits Binding
Displacement Displacement means that an area instance version with no active 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 NetWeaver release) 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
Transactional Areas and Propagation 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
Transactional Areas and Propagation Displacement Memory Limits Lifetime
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 shared memory
Lifetime
Lifetime is specified at design time using transaction SHMA
Demo
Demo 3
Exercise
Exercise 3
Encapsulation Avoid direct access to shared memory area instances
Session Reader
Area Instance1
Reader Instance2 Reader Instance3 Writer
Broker Instead, it is recommended to communicate with an area via a broker class that encapsulates
Area initialization Area access Lock administration Authority checks
Session Reader
Area Instance1
Reader Broker Reader Instance3 Reader Instance2
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 data between 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 SAP Education Training Opportunities

http://www.sap.com/education/
Related Workshops/Lectures at SAP TechEd 2004

ABAP201, 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
SAP Developer Network

Look for SAP TechEd 04 presentations and videos on the SAP Developer Network. Coming in December. http://www.sdn.sap.com/
Questions?
Q&A
Feedback
Please complete your session evaluation. Be courteous deposit your trash, and do not take the handouts for the following session.
Thank You !
Copyright 2004 SAP AG. All Rights Reserved

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.

SAP Shared Memory Presentation

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP Shared Memory Presentation

Uploaded by

Copyright:

Available Formats

Session ID: ABAP251 ABAP Shared Objects

Shared Memory Programming Made Easy

Rolf Hammer, SAP AG Holger Janz, SAP AG

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

SAP AG 2004, SAP TechEd / ABAP251 / 3

Motivation Basic Concepts Advanced Features 1 Advanced Features 2

What is Shared Memory ?

Different kinds of main memory on an application server

to a single user session be accessed by a different user session user isolation

Shared Memory (SHM)

across session boundaries access control in a business application context

SAP AG 2004, SAP TechEd / ABAP251 / 6

Data Access without Buffering

SAP AG 2004, SAP TechEd / ABAP251 / 8

Data Access without Buffering Common data

SAP AG 2004, SAP TechEd / ABAP251 / 9

Data Access without Buffering Common data

Common Data User X Session

Common Data User Y Session

Common Data User Z Session

SAP AG 2004, SAP TechEd / ABAP251 / 10

Data Access with Buffering by Copy

SAP AG 2004, SAP TechEd / ABAP251 / 12

Data Access with Buffering by Copy Common data

SAP AG 2004, SAP TechEd / ABAP251 / 13

Data Access with Buffering by Copy Common data

SAP AG 2004, SAP TechEd / ABAP251 / 14

Data Access with Buffering by Copy

Common Data User X Session

SAP AG 2004, SAP TechEd / ABAP251 / 15

Data Access with Buffering by Copy

Common Data User X Session

Common Data User Y Session

Common Data User Z Session

SAP AG 2004, SAP TechEd / ABAP251 / 16

Data Access with in Place Buffering

SAP AG 2004, SAP TechEd / ABAP251 / 18

Data Access with in Place Buffering

SAP AG 2004, SAP TechEd / ABAP251 / 19

Data Access with in Place Buffering

SAP AG 2004, SAP TechEd / ABAP251 / 20

Benefits for Application Programming

Significant boost in overall performance due to

is kept only once in memory is aggregated only once

Reduced runtime costs

Reduced maintenance costs due to

SAP AG 2004, SAP TechEd / ABAP251 / 22

Applications Using Shared Objects

Master Data Framework (Financials Basis)

SAP AG 2004, SAP TechEd / ABAP251 / 23

Motivation Basic Concepts Advanced Features 1 Advanced Features 2

Main usage scenarios

Coarse granular locking concept

SAP AG 2004, SAP TechEd / ABAP251 / 26

Areas and Area Instances Shared object memory

Shared object areas

Shared object area instances

SAP AG 2004, SAP TechEd / ABAP251 / 28

Area Instances and Objects

Inner references are allowed

SAP AG 2004, SAP TechEd / ABAP251 / 29

Instance Root: cl_my_root

SAP AG 2004, SAP TechEd / ABAP251 / 30

Shared Memory Enabling of a Root Class