LDQ: Überblick und Architektur 
Alternative Design Ideen
Die folgenden Punkte stellen alternative Design-Ideen dar:
NoSend Szenario, basierend auf dem Background Remote Function Call (bgRFC). Das bgRFC NoSend-Szenario verwendet verlinkte Listen für die Queues.
NoSend-Szenario, basierend auf dem klassischen Queued Remote Function Call (qRFC). Das qRFC NoSend-Szenario wurde bis jetzt für MMW verwendet.
In der Spezifikationsphase wurden Prototypen für LDQ und die beiden alternativen Designideen erstellt und hinsichtlich ihrer Leistungsfähigkeit beim Lesen und Schreiben verschiedener Datensätze verglichen. Die Option LDQ erwies sich gegenüber den Alternativen hinsichtlich Leistungsfähigkeit und Wartbarkeit als überlegen (siehe auch "bgRFC NoSend MMW Performancedaten").
Local Data Queue: Überblick
Wiederverwendung/Verwendete Komponenten und Abhängigkeiten
LDQ ist eine Re-Implementation und Re-Design des qRFC NoSend-Szenarios.
Einschränkungen
Das Monitoring von Local Data Queues ist nicht Gegenstand dieser Beschreibung.
Detailiertes Design
Explicit und Implicit Commit
Alle Methoden der LDQ Klassen benötigen einen Explicit Commit, um ihre Arbeit in der Datenbank abzubilden, mit Ausnahme der Methode CONFIRM_QUEUE_UNITS im Interface IF_LDQ_READER. Diese Methode führt einen Implicit Commit durch.
Abfolgenummer der Einheiten
Die Abfolgenummer einer Einheit in einer Queue beschreibt die Position der Einheit in der Queue. Abfolgenummern sind eindeutig und in aufsteigender Reihenfolge innerhalb einer Queue vergeben. Abfolgenummern werden nicht wiederverwendet nach dem Löschen von Einheiten in der Queue.
Confirm Often
Aus Performancegründen empfehlen wir Lese-Einheiten möglichst bald zu bestätigen (confirm), da alle Lese-Einheiten für ein mögliches erneutes Lesen im Speicher behalten werden.
Architektur
Das Klassendiagramm sieht folgendermaßen aus:
