Get Example source ABAP code based on a different SAP table
ABAP_BUFFER - Buffer Synchronization ITOC
Invalidating and Updating A buffered table or view usually exists in the table buffers of every ABAP_ASINSTANCE . If a program in one of the ABAP_ASINSTANCES modifies data from a table using AB_SQL , the data is updated as follows:
The data is modified in the database table on the database.
The buffers of the current ABAP_ASINSTANCE are invalidated immediately.
In changes made using work areas, the affected row is invalidated in tables with single record buffering. In generically buffered tables, the affected generic area is invalidated and in fully buffered tables, the whole table is invalidated.
In changes made using UPDATE ... SET ... WHERE ... or DELETE ... WHERE ..., the entire table is invalidated in tables with single record buffering and full buffering. In generically buffered tables, all generic areas are invalidated that are affected by a left-aligned generic subkey.
In buffered BEGIN_SECTION VERSION 5 OUT DDIC database views or END_SECTION VERSION 5 OUT CDS views, the entire buffer is invalidated regardless of the buffering type. In client-dependent views, however, this only affects the content of the current client.
The invalidated data is written to the log table DDLOG of the database interface.
Provided that no database commits have been performed for a change to the buffered table, all database reads on the ABAP_ASINSTANCE in which the change was performed access the database directly and bypass the buffer. After a database commit, the following applies to reads on this ABAP_ASINSTANCE :
In the case of single record buffering and a change, which only relates to a single record in this type of table, the buffer is updated immediately on read access.
In the case of generic, completely buffered tables, the number of reads that access the database directly bypassing the buffer is 5 by default. BEGIN_SECTION VERSION 5 OUT The value is specified in the profile parameter zcsa/inval_reload_c. END_SECTION VERSION 5 OUT The buffer is updated afterwards during the read with the data from the database.
On all other ABAP_ASINSTANCES , the buffers are still in the old state. Reads are still performed via the buffer and can potentially access obsolete data. The buffers of this ABAP_ASINSTANCE are synchronized using the following asynchronous method:
A synchronization is performed on every ABAP_ASINSTANCE in a specified time interval. The default interval is two minutes. BEGIN_SECTION VERSION 5 OUT The value is specified in the profile parameter rdisp/bufreftime. END_SECTION VERSION 5 OUT The database interface reads the log table DDLOG and invalidates the buffer content in the same way as on the ABAP_ASINSTANCE where the original change was made.
After synchronization, in the case of single record buffering and a change, which only relates to a single record, the buffer is updated via read access. In the case of generic, completely buffered tables, the number of reads that access the database is 5 by default. The buffer is only properly updated afterwards during the next read. BEGIN_SECTION VERSION 5 OUT The value is specified in the profile parameter zcsa/sync_reload_c. END_SECTION VERSION 5 OUT
Latest notes:
Asynchronous synchronization has the benefit of keeping the network load on the system low, particularly when compared with synchronous methods where each change made to the buffered data of an ABAP_ASINSTANCE is broadcast immediately to all other ABAP_ASINSTANCES . The drawback of asynchronous synchronization is that, unlike synchronous methods, the data is not up-to-date in the time between two synchronizations.
The asynchronous method of buffer synchronization affects the decision as to whether or not a DDIC database table can be buffered. Tables where many writes are performed are not suited to buffering, since the table buffers would then often be inconsistent, and the system would constantly be invalidating and loading the buffers.
Changes made using a WHERE condition place a far greater load on buffer management on the current ABAP_ASINSTANCE than changes made to single rows.
In fully buffered client-specified tables or views, it should be noted that generic buffering is performed internally with the client column as a generic key. This means that an invalidation of the entire buffer only affects the content of the current client.
In systems with only one ABAP_ASINSTANCE , it is not necessary to fill the log table DDLOG with the modifications of the buffered tables and this can be switched off by setting the profile parameter rdisp/bufrefmode to sendoff, exeauto. NON_V5_HINTS ABAP_HINT_END
Displacement If the free memory in the buffer falls below a preset value or the quality of access is poor, data is displaced from the buffer. The quality of access depends on the number of accesses that can be met directly from the buffer. The need for displacements is checked asynchronously at specific points in time that are determined dynamically using the accesses to the buffer, which means that the length of time between two displacements depends on the buffer load. Data is displaced from those tables that are accessed least often. Here, accesses to a table are weighted differently depending on the time they take place. Older accesses, for example, are weighted less than those that take place shortly before the displacement. This makes it possible to displace those tables from the buffer that are accessed a lot at one particular point in time but then no longer used.
Latest notes: The individual generic areas of generically buffered tables are handled like standalone tables, which means that certain generic areas of a table can be displaced while other generic areas of the same table are kept in the buffer. NON_V5_HINTS ABAP_HINT_END BEGIN_SECTION VERSION 5 OUT
Resetting the Buffer The table buffer of the current ABAP_ASINSTANCE can be reset by invalidating all its data. This is done by entering /$TAB in the command field in the standard toolbar in SAP GUI.
Latest notes: The table buffer should only be reset if inconsistencies have arisen in the buffer. It can take a long time to fill the table buffer in large systems and this can seriously affect performance. NON_V5_HINTS ABAP_HINT_END END_SECTION VERSION 5 OUT
