ABAP_to_the_Future

Troubleshooting 14.4
memory root object for read or update they have used WAIT UP TO X SECONDSand
tried again. When you start to use this pr ocess in real life, you’ll run into two
problems:
왘 No matter how many seconds you wait and no matter how many loops you do,
you cannot be sure that the build will be complete, the lock will be released, or
whatever. The only way to ensure this is an infinite loop, and that is not a viable
workaround. Pausing for 10 seconds is not much fun for the user either, especially
if he has a customer on the phone.
왘 The second and far more serious problem is that you cannot be sure where the
request will be called from. Th ere are certain places in which WAIT UP TO X
SECONDS causes a short dump; an update task springs to mind. The update task
performs a read request, which is usually harmless, and a short dump ensues.
Taking all this into consideration, when a user performs the first read request and
the instance does not yet exist, it’s better for that user to lose the battle than for
the whole system to lose the war. To make this happen, you can change the code
from Listing 14.4 to that shown in Listing 14.10.
CATCH cx_shm_no_active_version "Root class being built
cx_shm_inconsistent
"Root class is out of date
cx_shm_exclusive_lock_active "Someone trying to change data
cx_shm_change_lock_active "Someone trying to change the data
cx_shm_read_lock_active. "Amazingly, this can be an error
EXIT. "From do-end-do, we will use a real database read
ENDTRY.
Listing 14.10 Amended Read Lock Error Handling
Back in Chapter 7, you read about exce ption handling, and Listing 14.10 is an
example of a controlled panic response to an unexpected situation. You expect
the data to be in shared memory, but in the exceptional case in which it is not you
try an alternative strategy—that is, getting the data directly from the database—
and then resume where you left off.
Warning: Houston, We Have a Problem
One problem—without a solution, but worth noting: Whereas the SAP runtime system
looks after memory application for buffered tables, shared memory is on its own. If a
program calls a shared memory object and the shared memory is full, then an exception
is raised. In your own programs, you can add exception handling to prevent a short
dump, but a lot of the standard SAP programs have no such exception handling. Therefore,
if you aren’t careful, then you can start to cause standard SAP code that uses
653