Download chapter 5: 'Shared Memory Objects'
Excerpted from the book 'Next Generation ABAP Development', Authors Rich Heilman and Thomas Jung, ISBN 1592291392 Copyright 2007. Written permission from SAP PRESS is required for all other uses. Copyright © 2007 SAP PRESS America. All rights reserved. Email: customer@sap-press.com. SAP PRESS America, 11300 Rockville Pike, Suite 1100, Rockville, MD 20852-3030, USA.
Chapter Excerpt:
Shared Memory Objects
Shared memory objects are ABAP Object Instances, which can be stored in the shared memory area on an application server. Instead of going to the database to retrieve the required data, the data is accessed through the shared memory, thereby providing faster data retrieval.
This shared memory area can be accessed by all of the ABAP programs running
on that application server. Before the upgrade to SAP ERP 6.0, Russel
used the EXPORT/IMPORT statements with the SHARED BUFFER or SHARED MEMORY
extensions to access a similar memory buffer area. So what are the advantages
of using this new functionality?
- First, it is read access to shared memory without the need to copy it into user session
Requires Free Membership to View
When you register, you will start receiving targeted emails from my award-winning team of editorial writers. Our goal is to keep you informed on the hottest topics and biggest challenges faced by SAP professionals today.
Hannah Smalltree, Editorial Director
- memory. Technically, an application does a remote attach to the memory segment within shared memory and directly interacts with it.
- Secondly, the new shared memory technique is implemented through ABAP Objects; therefore, you are provided with robust tools to interact with shared memory through code. Ultimately, you aren't just buffering raw sets of data; you're also providing a shared mechanism to access the business logic wrapped around this data.
- There are also dedicated tools for the monitoring and administration of these shared areas and the objects within them. Transaction SHMM, for example, provides tools to monitor the size and number of objects within a shared area, as well as enabling administrators to force objects out of memory if necessary.
5.1 Getting Started
Russel has spent a considerable amount of time developing the database access layer for this project and wants to ensure that performance is at an optimal level. He decides to leverage the shared memory objects functionality to increase performance when accessing some of the data in the database.To use this feature of the ABAP runtime environment, Russel will have to create several new types of objects. Shared memory objects are implemented in two parts — the shared object root and area classes.
- The root class is the definition of the object that will be stored in shared memory. An instance (or multiple instances) of this class will reside in shared memory. Therefore this class's attributes should represent the data that you want cached and the methods of the class are the way that you access this data.
- The shared memory area class, on the other hand, will be a generated class. It abstracts a section of shared memory that is set aside for one or more instances of a particular root class. The methods of this area class provide the tools to attach to the shared memory area in order to read or manipulate it. The sole purpose of the area class is to return instances of the root class.
5.1.1 Area Root Class Creation
Russel decides that theZCS_COURSE table would be a good candidate to create
a shared memory object. Shared memory objects should primarily be used
for objects that are read often, but updated infrequently. This is due to the
locking mechanism that is used by shared objects. Although having multiple
read locks across separate user sessions is possible and is the norm, any form
of change lock is exclusive (i.e., it doesn't even allow parallel read locks on
the same area instance).
This does make ZCS_COURSE a good fit. New courses are rarely created or
changed during the school year. All updates are done all at once, before planning
for the next semester begins. Technically, this means that this table will
have frequent read accesses by students and teachers concurrently, but the
data will rarely change.
Russel's first step in implementing a shared memory object to represent ZCS_
COURSE is to create the area root class. This class implements the setter and
getter methods, which are used to access the data to be stored in the shared
memory area. It could also include business logic that further manipulates
the data during access operations. For instance, it might include calculations,
the results of which could also be stored in shared memory. This is where the
value of the shared memory object can extend well beyond the scope of just
the buffering of data stored within the database.
Russel creates the class ZCL_CS_COURSE_SHMO_ROOT and assigns it to the ZCS_
DDIC package using transaction code SE80 (see Figure 5.1).
Russel then sets the Shared Memory-Enabled checkbox on the Properties tab (see Figure 5.2). This tells the system that the class is eligible to be used as a root class for a shared memory object.
The idea of using shared memory objects is to store data in memory, which
can be used at runtime. Therefore, Russel needs to add an attribute to this
class that will hold the data retrieved from the ZCS_COURSE database table.
Although it is technically possible to create public attributes of the root class that can be accessed directly from an instance of the class, Russel wants to follow good object-oriented designs and encapsulate all of his attribute accesses within methods. This gives him more control in case he wants to embed other operations within an access to this attribute. Therefore he defines the attribute as a Private Instance attribute.
Chapter 5: 'Shared Memory Objects'
Visit the SAP Press website for a detailed description and to learn how to purchase this title.
This was first published in September 2007
Join the conversationComment
Share
Comments
Results
Contribute to the conversation