Documente Academic
Documente Profesional
Documente Cultură
steps
Shared Memory Programming: Now share objects into shared memory in the fastest way and with fewer steps
Applies to:
SAP NetWeaver Application Server release equal or higher than 6.40
Summary
This article deals about the technique of sharing the class instances and anonymous data objects into shared memory. This has got many advantages over the earlier memory sharing techniques in ABAP in terms of flexibility, speed and performance volumes for sharing data from within ABAP programs. Author(s): Priti Mulchandani Company: SAP Labs India Pvt. Ltd. Created on: 27 December 2006
Author Bio
Priti is working as development specialist in SAP Labs India Pvt. Ltd. from last 2 years, with 3 and half years of total SAP experience. She has mostly worked on different customer specific projects related to area of ISAFS and has keen interest on anything new in ABAP.
Shared Memory Programming: Now share objects into shared memory in the fastest way and with fewer steps
Table of Contents
Applies to: ........................................................................................................................................ 1 Summary.......................................................................................................................................... 1 Author Bio ........................................................................................................................................ 1 Why Shared Memory and History.................................................................................................... 3 Some Basics about Shared Object Memory.................................................................................... 3 How to Use SOM Simple Export and Import Programs............................................................ 6 Conclusion ....................................................................................................................................... 9 Copyright........................................................................................................................................ 10
Shared Memory Programming: Now share objects into shared memory in the fastest way and with fewer steps
Shared Memory Programming: Now share objects into shared memory in the fastest way and with fewer steps
Fig 1: Transaction SHMA Defining Shared memory Area and its properties Area Just think that you have to give a new name and reserve some piece of the SOM for sharing your own object -something like area for building your own house. Technically system differentiates one AREA from other AREA by some properties/characteristics. A class with the same area name gets automatically generated once you define your area in SHMA. Area Instance Can be compared with different instances at runtime of any usual class, but truly speaking its not the OO instance. It is again a sub portion of the defined area, which actually gets filled with data through our programs. We can export multiple real OO instances (multiple sets of data) from our programs to different SOM area instance.
Shared Memory Programming: Now share objects into shared memory in the fastest way and with fewer steps
Fig 2: SOM Area instances Root Class One of the very important properties of the AREA that we will define using SHMA. Truly this is the class whose instance (mentioned above as real OO instance), we will be storing in SOM from our program. Any access to area instance is always through root instance. This class is same as any other global final class but should necessarily have a property called Shared Memory Enabled Area Instance Version/Versioning Very unique concept that we didnt have so far. If a reader is reading the contents of particular SOM instance and the writer also wants to write or update new contents in same instance, then a new version gets generated every time. Something like - old, new, latest, being build, expired. There has to be always one version with which SOM runtime will work and just remember that a reader always reads active/last committed version if there are multiple versions in SOM. Meanwhile if Writer has finished updating and if a new active version is now available, the old version will be automatically garbage collected by SOM runtime. Locks in SOM If one writer is writing into same memory area instance, another user should not get access for writing again. Well the beauty is once you start writing in SOM, system will place a change lock, and hence no other writer can get the change access on the whole application server for same SOM instance. On the other hand, Readers lock remains in effect till current session. Thus with the help of above property, the lock mechanism assures us to get the access to the active/most recent version every time. Transactional commit Its difficult to assure the proper synchronization between memory and database contents in our programs sometimes, so this assures that only when you do db commit, the related content will be written to SOM. There are few other properties such as Propagation to propagate the changes of SOM from one application server to another of same SAP system Automatic preloads when someone has cleared/refreshed the contents in SOM (which is directly possible though single button or through different methods of generated area class), but you want to place it again automatically without manually executing your write/export program Freeing complete or part of memory Deciding the Size of memory area/instances (Also check abap/shared_objects_size_MB profile parameter) Client separation at memory level which is something similar to specifying client in select query.
Shared Memory Programming: Now share objects into shared memory in the fastest way and with fewer steps
This is basically done once at design time to define our areas and now its the time to move to simple programming to export and import something in these areas.
How to Use SOM Simple Export and Import Programs There is one important object called ARE AHNDLE which is a key to write or read objects in SOM. This is an instance of AREA class and allows us to do many more things with the help of generated area classs methods. AREA class is kind of wrapper which hides technicalities of how actually the OO-instances (root classs instances) are written inside SOM. In the place of Export and Import statements, we will be using write and read instance methods of the area class. This is kind of entry point from our program to root object in SOM instances. So for sharing data through our code, we will be using two instances AREA HANDLE and ROOT INSTANCE. Methods of AREA HANDLE will be used to place ROOT INSTANCE inside shared memory. Following well known ABAP statements are upgraded in the context of SOM DEFINE CLASS zcl_my_root SHARED MEMORY ENABLED With this you say that your class is going to also take place in SOM. Check out properties tab for the same in SE24 while defining root class. CRETAE OBJECT myRoot AREA HANDLE myShmHandle CREATE DATA dref AREA HANDLE myShmHandle So we should now realize the fact that we not only store object reference but data references also (from release 7.0). Our piece of Export code or WRITE program should look like this:
\\* Define Area handle and Root instance Data : myShmHandle TYPE REF TO zcl_my_area, myRoot TYPE REF TO zcl_my_root. zcl_my_area is same as area name
*Get area class instance or area handle and use handles ATTACH_FOR_WRITE *method to export your data in SOM. myShmHandle = zcl_my_area=>attach_for_write( ).You can specify instance name, here DEFAULT is used
* Start filling the contents of shared memory enabled root class into SOM instance CREATE OBJECT myRoot AREA HANDLE myShmHandle. myRoot->name = `My first area instance`. name is simple public attribute in root class APPEND `Harry` TO myRoot->itab. itab defined as public internal table of type string * dref is data reference to string. You can even try with dynamic data types CREATE DATA myRoot->dref AREA HANDLE myShmHandle. myRoot->dref->* = `Jul-04-2005`.
IF ... * tell area handle who is going to work as root- dont miss this, Root is always stored as attribute of area class myShmHandle->set_root( myRoot ). * Finally put the root instance (and hence all its attributes/data) in SOM myShmHandle->detach_commit( ). ELSE.
Shared Memory Programming: Now share objects into shared memory in the fastest way and with fewer steps
myShmHandle->detach_rollback( ). ENDIF. * After this if you will fill in attributes of root instance w/o above blocks; that wont sit in SOM at all . *However if you repeat another similar block, this time with new data for example in root object, a new SOM instance will\ * get created
.
Now lets have a look at READ Program This mostly contains opposite methods of AREA class to import the instances:
\\ DATA: myShmHandle TYPE REF TO zcl_my_area, myRoot txt TYPE REF TO zcl_my_root, TYPE string.
* This time get the handle through static ATTACH_FOR_READ method of area class myShmHandle = zcl_my_area=>attach_for_read( ). Try catching different exceptions of methods
*Root instance should already be active and present as writing would have been already done using export pgm. myRoot = myShmHandle->root.
*Now read the contents as you normally do w/o SOM READ TABLE myRoot->itab INTO txt INDEX 1. WRITE: / txt.
CONCATENATE myRoot->name myRoot->dref->* INTO txt SEPARATED BY space. WRITE: / txt. *Tell system, that you have finished reading, this will remove read lock myShmHandle->detach( ).Even if you dont detach, sys will remove at the end of pgm
So with this, we are done with placing our references/data/complex structures in the memory. But how we will be sure it is really working, questions like Can I see my memory contents after placing? Can I delete un-needed objects? Can I go and see how many readers are currently reading the object? Or who is the writer, so that I can fine tune my program always hover around us while dealing with memory programs. And answer to these and many more questions finally lies with the interesting transaction SHMM A powerful monitor tool. Check your areas, Instances, Versions, Locks, and even Data/attributes of the instances of root class and try many more things such as delete.
Shared Memory Programming: Now share objects into shared memory in the fastest way and with fewer steps
Shared Memory Programming: Now share objects into shared memory in the fastest way and with fewer steps
Conclusion
To end with, there are few restrictions with SOM programming model. As nothing can be absolutely the best option, there is always a chance of getting something more powerful than this. But it is good to end with interesting true figures: With several hundreds of users, a control and monitor tol took 16000 ms whereas shared memory program just took 3000 ms. this is because-> Without SOM: there was 3 MB memory per user session (50 users = 150 MB) -> With SOM: 3 MB for all users now there is direct copy-free access to shared memory i.e. no copy to session memory or roll area Result Access performance: SOM is 100 times faster at first access in a user session!!
Shared Memory Programming: Now share objects into shared memory in the fastest way and with fewer steps
Copyright
Copyright 2006 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, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated 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. These materials are provided as is without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials. SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages. Any software coding and/or code lines/strings (Code) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.