New Buffering Method � Parallel Buffering

This buffering method is an enhancement of the Extended Local Buffering

Method ( Local table + Work Process Id)

The reason behind this new buffering method is the following:

The extended local buffering, which works well with parallel online processing
and also with online processing parallel to a long running batch job, is unsuited
for parallel batch processing. The reason for this is, as soon as a long running
batch process which draws many numbers from the same number range interval reloads
from NRIV ,
a lock on NRIV will be set. A second parallel process can work unimpeded only as
long as
it still has numbers in its buffer. As soon as it has to reload, it has to wait for
the lock
of NRIV set by the first process to be freed upon the first process issuing a
COMMIT WORK.
As such, the locking problem is only postponed but not solved.

This problem is solved by the new buffering method .

There is also a secondary problem with the extended local buffering:

The name of the instance is in the extended local buffering limited to
18 characters (see note 179224) while the SAP system allows 20
Characters.
Customers using this feature to the maximum see themselves contrived to
reduce this length later when the necessity to use extended local buffering arises.

This limitation does not exist anymore with the new buffering method.

Due to the advantages of the parallel buffering, it is to be expected that in the

long
run it will become the standard buffering method whenever main storage buffering is
not
usable due to the known shortcoming (i.e. loss of numbers due either to restart of
the
instance or rollbacks by the application).

Technical description

The local buffer is not anymore in the table NRIV_LOKAL, but in the new table
NRIVSHADOW.
Like it was the case with NRIV_LOKAL it contains ahead of the NRIV key fields the
instance and work
process id � this time with a length of 43 in order to accommodate both future
enlargements of the
instance name and the work process. As it was the case with the extended local
buffering, numbers
will be drawn from NRIV and provided from NRIVSHADOW to the application program.

The key of NRIVSHADOW has two additional fields,

ROLLFLAG Overflow flag

SRTF Buffer number

This allows the administration of several number buffers for the same instance and
process id.
These fields allow the administration of several packages of numbers for each
instance and process ID.
This in turn makes possible reloading during one work process of several packages
of numbers which can be reused in
case of a ROLLBACK.
The simplest way to describe the technology is the following:
Numbers drawing is here separated into two distinct parts:
1) Downloading numbers from NRIV to the reusable buffer in NRIV_SHADOW; this
process is one-way and can be
committed immediately with no further consequences. For this the same technique is
used as in the main storage
buffering, which means using a parallel process in which this download can be
committed without affecting with
this COMMIT the main process in which the application program is running;
2) All other operations are taking place in NRIVSHADOW and are subject to COMMITs
or ROLLBACKs by the
application making the downloaded buffers reusable if necessary.
The correct order of the buffers is determined using the field SRTF and if
necessary in case of overflow
of SRTF using the ROLLFLAG helping the procedure to get around the bend when SRTF
starts again from initial value
(can happen once in years).

Advantages:
Externally the new buffering behaves exactly like the local extended buffering,
which means there are no gaps
in the numbering, but the numbers will still be drawn in an apparent random way ;
the only situation when gaps
can appear is documented in the FI-note 175047 (application error).
For year dependent number range objects numbers in buffers but not yet used at year
end will never be drawn, but
they can be documented exactly as it was the case with the local buffering, the
only difference being the name
of the documenting report, which is now RSSNR0S1. It documents BOTH the numbers
with parallel buffering AND the
ones with local buffering, extended or not.
The only difference � internal � is that exactly like in main memory buffering,
there are no locks under no
circumstances for the objects buffered with the parallel buffering, likewise to the
main storage buffering.

Until now, the only way to circumvent the problem of parallel background processing
without gaps in numbering was
to set the buffer to a very high number: thousands of numbers in each buffer.
Multiplied with the number of instances
and the number of work processes in every instance, this led to a high �burn rate�
of the numbers to be allocated.
Due to the back door method of reloading, this new buffering method can allow
reducing the number of numbers in the buffer very much.

SAP will make available the new buffering as a standard starting with release stand
4.6C.
When no special arrangements are made regarding availability of free RFC processes
these are sought in the
local instance (destination NONE) . This can lead under circumstances to a
bottleneck under high load. Therefore
it is alternately possible to specify a destination which should be defined via
SM59 and which has load balancing .
Then this destination would seek a free DIA process in any available instance for
the parallel NRIV update. For this
destination table TNRO was enlarged with a field to contain it.
Another possibility is to set up a dedicated instance with DIA work processes as
specified in these cases by the
RFC documentation. Still, destination NONE (default) is slightly preferable
whenever possible as the RFCs are much
more rapid due to the missing RFC logon in this case.