This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Object Transaction ServiceObject Transaction Service (OTS)• Bestandteil der CORBA Common Object Services
(COS Transactions)• Objektorientiertes Äquivalent des X/Open DTP-Standards
– Verwendet XA Interface der beteiligten DatenbankenOTS spezifiziert Schnittstellen (via IDL) und Funktionalität eines TransaktionsdienstesGrundidee: Jeder Transaktion wird ein Transaktionskontext zugewiesen• Methodenaufrufe werden mit diesem Kontext assoziiert, daher
Zuordnung unterschiedlicher Requests zu einer Transaktion möglich• OTS-Äquivalent zur Transaktions-ID (TXID), die diese Aufgabe als Teil
– implementiert, wenn auch nichtunbedingt CORBA konform
– implementiert in einer nicht demStandard entsprechenden Form
– angekündigt– unbekannt
Y
#
+
?
Nm Naming Lf Lifecycle Ev Event Tr Trading Cc Concurrency Ex Externalization Po Persistent Objects Tx TransactionsQr Query Tm Time Pr Properties Sc Security Li Licensing Av Audio/Video Streaming
• Alles innerhalb dieser Transaktionsklammer wird mit ACID-Garantien ausgeführt (Koordination durch 2PC-Protokoll; Verwendung der XA Schnittstelle der beteiligten Datenbanken)
• Unterstützung im OTS zwingend vorgeschrieben
Nested Transactions (Geschachtelte Transaktionen)• Idee: Unabhängige Subtransaktionen innerhalb einer Transaktion
– Dadurch: mehr Flexibilität bei der Fehlerbehandlung• Unterstützung lediglich optional, zudem ist nur eine geschlossene
Geschlossen geschachtelte TransaktionenSubtransaktionen können mit Commit(vorläufig) beendet werden, sind aber von parallelen Subtransaktionen isoliertErst nach dem Commit der top-levelTransaktion erfolgt auch das definitive Commit aller SubtransaktionenBei Rollback der top-level Transaktion werden ALLE Subtransaktionen rückgesetzt (auch wenn sie bereits ein Commit durchgeführt haben)D.h. ALLE erfolgreich abgeschlossenen Subtransaktionen werden geschlossen innerhalb der Kontrollsphäre (ACID) der top-level Transaktion ausgeführtAber: Commit der top-level Transaktion ist auch möglich, wenn einzelne Subtransaktionen rückgesetzt werden mussten. Dadurch einfachere Fehlerbehandlung durch Alternativen (z.B. T1112 als Alternative zu T1111)
Transaktionskontext mittels OTSExplizites Setzen eines Transaktionskontextes durch die CosTransactions::TransactionFactory• Liefert Control-Objekt zurück, das Transaktion spezifiziert • Dies kann explizit mit Methodenaufruf weitergegeben werden
Implizit per Current-Objekt. Dies ist ein Pseudo-Objekt, das die aktuelle Transaktion repräsentiert• Durch das Current-Objekt wird jedem Thread implizit ein
Transaktionskontext zugewiesen• Beim Methodenaufruf propagiert der ORB automatisch diesen Kontext an alle
transaktionalen Objekte, d.h. an solche, die vonCosTransactions::TransactionalObject abgeleitet sind(dies sind transaktionale Server oder recoverable Server)
– Dies kann über mehrere Aufruf-Hierarchien hinweg gehen– Dabei: Kopie des Transaktionskontexts durch den ObjectAdapter
• Möglichkeit zum Starten und Beenden (Commit bzw. Rollback)
In beiden Fällen erfolgt die Verwaltung und Abwicklung des 2PC-Protokolls automatisch durch den CosTransactions::Coordinator
enum Status {StatusActive, StatusMarkedRollback,StatusCommitted,StatusPrepared,StatusRolledBack,StatusUnknown,StatusNoTransaction,StatusPreparing,StatusCommitting,StatusRollingBack
IDL des OTS (2) – TransactionFactory & ControlTransactionFactory• Erlaubt einem Client, eine neue Transaktion zu starten
(im Falle von geschachtelten Transaktionen: Erzeugung einer top-level Transaktion); dazu muss der Client von CosTransactions::TransactionFactory abgeleitet sein
interface TransactionFactory { Control create(in unsigned long time_out);
/* Erzeugt neue top-level Transaktion und gibt das zugehörige Control-Objekt zurück */
... };
• create generiert ein Control-Objekt(über das die neue Transaktion identifiziert wird)
interface Control { Terminator get_terminator (); Coordinator get_control (); };
IDL des OTS (4)Der OTS verwendet ein 2PC-Protokoll. Das Resource-Interface beinhaltet die Operationen, die vom OTS hierzu von den Ressourcen vorausgesetzt werden und vom OTS dort aufgerufen werden
IDL des OTS – implizite Weitergabe des Tx-Kontexts
Das Current-Interface spezifiziert alle Operationen, die ein transaktionaler Client bzw. ein Teilnehmer an einer Transaktion verwenden kann, wenn der Transaktionskontext implizit durch die CORBA-Laufzeitumgebung (ORB) propagiert wird
interface Current {
void begin ();void commit ( in boolean report_heuristics );void rollback();Status get_status();Control get_control ();void set_timeout ();...
};
Das TransactionalObject-Interface gibt an, dass ein Objekt transaktional ist und daher im Falle der impliziten Weitergabe des Transaktionskontextes diesen vom Client, der eine Transaktion initiiert hat, auch bekommt
Beispiel-IDL einer Ressource mit OTSAccount-Objekte sollen automatisch den aktuellen Transaktionskontext erhaltenZusätzlich unterstützt die Ressource, die den expliziten Zustand von Account verwaltet, das 2PC-Protokoll (Account-Objekte müssen sich daher als Ressourcen anmelden)
Deklarative TransaktionssemantikDer OTS ermöglicht es auf (mehr oder weniger) elegante Weise, verteilte Objekte in einen gemeinsamen Transaktionskontext zu bringenAllerdings muss der Entwickler von Server-Objekten bereits wissen, ob und wenn ja in welcher Rolle seine Server-Objekte in einer verteilten Transaktion teilnehmen.Probleme können beispielsweise auftreten, wenn• Objekte, die von TransactionalObject abgeleitet sind, nicht an einer
Transaktion, deren Kontext implizit weitergegeben wird, teilnehmen sollen, oder
• Wenn ein Methodenaufruf (mit explizit weitergegebenem Control-Objekt) ausnahmsweise eine neue Subtransaktion starten sollAbhilfe (sehr umständlich): Server-Klasse editieren und neu kompilieren
Könnte man nicht die Server-Objekte unabhängig von den möglichen späteren Verwendungszwecken entwickeln und die Transaktions-semantik bei jeder konkreten Verwendung individuell deklarativspezifizieren?
Container, Deployment und Interception …Genau diese Idee wird von modernen Objekt-Transaktions-Monitoren verfolgt • z.B. von Enterprise JavaBeans
(diese werden im folgenden Kapitel ausführlich dargestellt; deshalb werden wir hier die Idee der deklarativ spezifizierten Transaktionssemantik nur kurz anreissen und beim nächsten Mal vertiefen)
Voraussetzung hierzu• Laufzeitumgebung für Server-Objekte (Container)• Möglichkeit zur Spezifikation von Transaktionseigenschaften
(Deployment)• Anwendung der spezifizierten Semantik zur Laufzeit (Interception)
– Abgreifen von (entfernten) Methoden-Aufrufen BEVOR dieServermethoden ausgeführt werden
– Auslesen der gewünschten Transaktionssemantik aus der Deployment Description
– Methodenaufruf mit entsprechendem Transaktionskontext assoziieren (bzw. neuen Kontext generieren)
Komponenten oder Dienste werden auf einem System implementiertExport-Funktionalität für diese ImplementierungenImport-Funktionalität erlaubt das Einspielen vorher exportierter Implementierungen auf jedem System mit gleicher Infrastruktur ohne RekompilierungDeklarative Bestimmung von Eigenschaften der Komponenten:• Transaktionen• Resource Pooling• Zugriffsrechte• …
Transaktionen als StandarddienstTransaktionssteuerung • im Client mittels expliziter Aufrufe• automatisch und deklarativ auf Komponentenebene durch den
Container
Transaktionsattribute für Methoden• Disabled: nicht in einem Transaktionskontext ausgeführt• Not Supported: ohne Transaktionskontext ausgeführt• Supported: in einem Transaktionskontext ausgeführt, falls bei Aufruf
einer existiert; sonst ohne Transaktionskontext • Required: immer in einem Transaktionskontext ausgeführt, der ggf.
auch neu erzeugt wird, falls noch nicht existent• Requires New: immer in einer neu erzeugten, eigenständigen
Transaktion ausgeführt
Implementierung: Zwei-Phasen-Commit bei verteilten Transaktionen – transparent durch Interception
Das Prinzip der InterceptionObjekte laufen in Containern ab.Mit dem Einspielen eines neuen Objektes in einen Container wird die Schnittstelle dieses neuen Objektes dem Container bekannt gemacht.Das ermöglicht für den Container:• Container-generierte Objekte mit gleicher Schnittstelle zu
definieren – sogennante Wrapper;• Methoden-Aufrufe nicht direkt an die Objekte zu senden,
sondern vorher über die eigenen Wrapper-Implementierungen umzuleiten;
• in den Wrappern nützliche Informationen über die Methodenaufrufe festzuhalten, etwa um Transaktionseigenschaften herzustellen;
• und schliesslich den Methodenaufruf vom Wrapper an das eigentliche Objekt weiterzureichen.