Entering content frameThis graphic is explained in the accompanying text Example for Buffer Synchronization Locate the document in its SAP Library structure

The following example shows how the local buffers of the system are synchronized. We have a system with two application servers, called Server1 and Server2.

Initial situation: Neither server has yet accessed records of the fully buffered table TAB. The local buffers of both servers do not yet contain the records of the table.

Event 1: Server 1 reads records from table TAB in the database.

Event 2: Table TAB is completely loaded into the local buffer of Server 1. Accesses by Server 1 to the data of table TAB now use the local buffer of this server.

Event 3: Server 2 accesses records of the table. Since the table is not yet in the local buffer of Server 2, the records are read directly from the database.

Event 4: Table TAB is completely loaded into the local buffer of Server 2. Server 2 then also accesses the data in TAB using its local buffer the next time it reads.

This graphic is explained in the accompanying text

Event 5: Server 1 deletes records from table TAB and updates the database.

Event 6: Server 1 writes an entry in the synchronization table.

Event 7: Server 1 updates its local buffer.

This graphic is explained in the accompanying text

Event 8: Server 2 accesses the deleted data records. Since table TAB is in its local buffer, access uses this local buffer.

Server 2 therefore finds the records, although they are no longer in the database table!

If the same access were executed from an application program on Server 1, this program would see that the records no longer exist. The behavior of an application program at this time therefore depends on the server on which it is executing!

This graphic is explained in the accompanying text

Event 9: It is now time for synchronization. Both servers check the synchronization table to find out whether one of the tables in its local buffer has been changed in the meantime.

Event 10: Server 2 finds that table TAB was modified by Server 1 in the meantime. Server 2 therefore invalidates the table in its local buffer. The next time Server 2 accesses the data in table TAB, it therefore uses the database. Server 1 does not have to invalidate the table in its buffer because it alone changed table TAB. Server 1 therefore uses its local buffer the next time it accesses records of table TAB.

This graphic is explained in the accompanying text

Event 11: Server 2 again accesses records of table TAB. Because TAB was invalidated in the local buffer of Server 2, access uses the database.

Event 12: The table is again loaded into the local buffer of Server 2. The information about table TAB is now consistent for both servers and the database.

This graphic is explained in the accompanying text

Leaving content frame