LDQ: Overview and Architecture
Local Data Queue: Overview
Reuse/Components Used/Use Dependencies
LDQ is a reimplementation and redesign of the qRFC NoSend scenario
Alternative Design Ideas
The alternative design ideas are as follows:
- NoSend scenario based on the background Remote Function Call (bgRFC). The bgRFC NoSend scenario uses linked lists for the queues.
- NoSend scenario based on the background Remote Function Call (bgRFC). The qRFC NoSend scenario has been in use for MMW thus far.
In the specification phase, prototypes for LDQ and for the two alternate design ideas were built and compared for reading and writing various data volumes. The LDQ option proved superior to the alternatives both in performance and maintainability (see “bgRFC NoSend MMW Performance Figures”).
Constraints
Monitoring Local Data Queues requires its own budget and is not covered here.
Detailed Design
Explicit and Implicit Commit
With one exception, all methods of LDQ classes require an explicit commit to persist their work in the database. The exception to this rule is the CONFIRM_QUEUE_UNITS method in the IF_LDQ_READER interface. This method executes an implicit commit.
Sequence Number of Units
The sequence number of a unit in a queue describes the position of the unit in the queue. Sequence numbers are unique and in ascending order in a queue. When units are deleted from the queue, their sequence numbers are not reused.
Confirm Often
For performance reasons, you are strongly advised to confirm read units as soon as possible, since all read units are stored and read again if required.
Architecture
The class diagram is as follows:
