1. Verteilte Datenbanken -
Persistant Queues
Arno Schmidhauser
Letzte Revision: März 2011
Email: arno.schmidhauser@bfh.ch
Webseite: http://www.sws.bfh.ch/db

2. Nachteile des Two Phase Commit
(2PC) in globalen Systemen
• 2PC verfolgt das ACID-Prinzip und erreicht damit eine
globale Konsistenz unmittelbar nach jeder Transaktion.
• Die Verfügbarkeit der benötigten Datenbanken ist aber
nicht immer kontrollierbar.
• Die Öffnung von Systemresourcen für das 2PC, wie der
Zugriff auf die beteiligten Datenbanken, die 2PC-Fähigkeit,
die Verfügbarkeit der gewünschten 2PC-API's für den
Transaktionsmanager usw., ist nicht immer wünschens-
wert oder möglich.
• Die Kontrolle über die Struktur der beteiligten
Datenbanken, insbesondere über Unternehmen hinweg, ist
nicht immer gegeben.

3. BASE ergänzt ACID
• Zunehmender Paradigmenwechsel: Eine verfügbare
Applikation ist in vielen Fällen wichtiger als globale
Konsistenz. Das C im ACID wird abgeschwächt zu:
– Basically Available (Vorrangige Verfügbarkeit)
– Soft State (Sichtbare Zwischenzustände erlaubt)
– Eventually Consistent (Konsistenz mit Verzögerung)
• Persistent Message Queues (PMQ) sind eine wichtige
Realisierung dieses Prinzips

4. PMQ - Beispiel
• Das Bearbeiten und der Versand einer Bestellung hängen
zeitlich unkritisch vom unmittelbaren Einkauf ab.
PMQ Versandaufträge
Shop/Bestellung Lager/Versand
(Amazon US) (DE)
DB 1 DB 2
begin transaction begin transaction
// Message erstellen message = q.dequeue()
// aus DB1 // Message in DB2
q.enqueue ( message ) // hinein verarbeiten
commit commit

5. PMQ – Grundsätze (1)
• Versenden, Empfangen und Bearbeiten einer Message
kann als asynchrone Transaktion auf einem globalen
Datenbestand, mit zwischenzeitlich inkonsistentem
Zustand, angesehen werden.
• Versand und Empfang können asynchron stattfinden.
• Werden die Message selbst in einer Datenbank
abgespeichert, ist deren Verarbeitung nach einer
bestimmten Zeit garantiert.
• Die Verarbeitung ist skalierbar durch parallele arbeitende
Message-Produzenten und Message-Konsumenten.

6. PMQ – Grundsätze (2)
• Message Queues haben generische, aplikationsunab-
hängige Eigenschaften, was ihre Verwendung einfach
macht:
– First-in / First-out Prinzip
– enqueue() und dequeue() Methoden
• Hilfsmethoden ergänzen das generische Verhalten
– Umgang mit vergifteten Messages
– Timeouts für nicht abgeholte Meldungen
– Filter für Typ, Absender, Empfänger etc.
– Sortierung nach Priorität, Zeit etc.

7. Messageing = zeitlich entkoppelte
Transaktionen (1)
Applikation 1 Applikation 2
DB 1 DB 2
lokale Transaktion lokale Transaktion
Message Message
begin transaction DB1 begin transaction mDB
// Message erstellen aus DB1 // Message konsumieren
commit DB1 message = q.deueue ()
Messageing-System
begin transaction mDB commit mDB
// Message in mDB übertragen begin transaction DB2
q.enqueue ( message ) // Message verarbeiten in DB2
commit mDB mDB commit DB2

8. Messageing = zeitlich entkoppelte
Transaktion (2)
Applikation 1 Applikation 2
DB 1 DB 2
lokale Transaktion lokale Transaktion
Message Message
begin transaction DB1 begin transaction DB2
// Message erstellen aus DB1 begin transaction mDB
begin transaction mDB // Message konsumieren
Messageing-System
// Message in mDB übertragen message = q.deueue ()
q.enqueue ( message ) commit mDB
commit mDB // Message verarbeiten in DB2
commit DB1 mDB commit DB2

9. Messageing mit Two Phase Commit
Applikation 1 Applikation 2
DB 1 DB 2
Two Phase Commit Two Phase Commit
Message Message begin transaction DB2, mDB
begin transaction DB1, mDB
// Message aus mDB konsumieren
// Message erstellen aus DB1
message = q.deueue ()
// Message in mDB übertragen
Messageing-System // Message verarbeiten
q.enqueue ( message )
commit DB2, mDB
commit DB1, mDB
mDB

10. PMQ Implementation mit Database API
• Zwei Prozesse greifen via API auf eine Queue-Datenbank zu
(enqueue()/dequeue() Operationen über JDBC o.ä.).
• Die Queue-Datenbank befindet sich im lokalen Applikations-Umfeld.
• Im einfachsten Fall alle drei DB's identisch.
• 2PC ist jeweils zwischen DB1 und QueueDB resp. zwischen QueueDB
und DB2 möglich.
Prozess 1 Prozess 1
PMQ-API PMQ-API
Prozess Prozess
DB 1 DB 2
Queue
DB

11. PMQ Implementation mit SOA
• Die PMQ ist ein vollständig unabhängiger Dienst, ev.
geografisch und unternehmensmässig getrennt von den
Message-Produzenten und –Konsumenten.
• PMQ-System wird über REST/HTTP- oder Web-Service
angesprochen.
• Die Queue-Datenbank wird von einem unabhängigen
Datenbanksystem (Resource Manager) kontrolliert.
• Kein 2PC sinnvoll.
• Beispiel Amazon SQS
– HTTP Interface
– WSDL Interface
• Viele weitere professionelle Queueing Systeme, z.B. IBM
WebSphere MQ, Microsoft, Oracle, Apache usw.

12. Vollständig sicheres Messageing ohne
Two Phase Commit
Messageing-Applikation
Message
Message
Nr 12
Nr 12
Sender Empfänger
LMN
(z.B. 11)
DB 1 DB 2