Kapitel 4: Vorlesung OTM – 1Objektverwaltung höherer Ordnung (OHO) – SS 2003
3.3 Objekt-Transaktions-Monitore (OTM)Objekt-Transaktions-Monitore (OTM)• Verschmelzen von Distributed Object Management (DOM)
und TP-Monitor-Konzepten
Explizite Transaktionssemantik• Beispiel: CORBA + OTS
Deklarativ spezifizierte Transaktionssemantik • Container, Deployment und Interception
Kapitel 4: Vorlesung OTM – 2Objektverwaltung höherer Ordnung (OHO) – SS 2003
OTM = TP-Mon + DOMTP-Monitor: Verteilte Transaktionen• Erleichterter Umgang für den
Programmierer bei verteilten Transaktionen steht im Vordergrund
• Verwendung des X/Open-Standards für verteilte Transaktionen
DOM: Verteilte Objekte• Erleichterung der Programmie-
rung durch Objektorientierung, sowie Realisierung von Ortstransparenz, Plattform- und Sprachunabhängigkeit steht im Vordergrund
• Verwendung eines Objekt-Busses (wie z.B. dem Object Request Broker, ORB)
+Objekt-Transaktions-Monitore (OTM):
Verteilte Transaktionen über verteilten Objekten
Kapitel 4: Vorlesung OTM – 3Objektverwaltung höherer Ordnung (OHO) – SS 2003
Von TP-Monitoren …
Präs
enta
tion
Appl
icat
ion
Serv
ice
A
TP-Monitor
Appl
icat
ion
Serv
ice
B
Appl
icat
ion
Serv
ice
CDBMS DBMS DBMS
RPC
Anw
endu
ngsl
ogik
Dat
en
Kapitel 4: Vorlesung OTM – 4Objektverwaltung höherer Ordnung (OHO) – SS 2003
DBMSDBMSDBMS
Objekt-Bus
… zu Objekt-Transaktions-Monitoren
OTMObject
AObject
B
ObjectC Object
D
Präs
enta
tion
Anw
endu
ngsl
ogik
„View-Objekte“
Objekt-
Transaktions-Service
Server-Objekte
Dat
en
Kapitel 4: Vorlesung OTM – 5Objektverwaltung höherer Ordnung (OHO) – SS 2003
OTMs in der Praxis
CORBA• ORB + OTS (Object Transaction Service)• Beschreibung des OTS in diesem Abschnitt
Java Transaction Service (JTS)• Java-Implementierung des OTS• Mehr dazu in Kapitel 5 (Enterprise JavaBeans)
COM+• DCOM + MTS (Microsoft Transaction Server)
Kapitel 4: Vorlesung OTM – 6Objektverwaltung höherer Ordnung (OHO) – SS 2003
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
des TxRPC im TP-Monitor-Fall übernommen hat
Kapitel 4: Vorlesung OTM – 7Objektverwaltung höherer Ordnung (OHO) – SS 2003
Verbreitung des OTS
Quelle: http://www.jetpen.com/~ben/corba/cosmatrix.html
Stand: August 2000
– 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
Legende:
Kapitel 4: Vorlesung OTM – 8Objektverwaltung höherer Ordnung (OHO) – SS 2003
OTS: Unterstützte TransaktionsmodelleFlat Transactions• Transaktionsklammer durchbegin transaction...end transaction (entweder commit oder rollback)
• 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
Schachtelung (closed nested transactions) vorgesehen
Kapitel 4: Vorlesung OTM – 9Objektverwaltung höherer Ordnung (OHO) – SS 2003
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)
begintransaction commit
callsubtx
callsubtx
begin commit begin commit
call
begin commit
call call
begin
begin
commit
commit
call
begin commit
T1
T11 T12
T111 T121
T1111 T1112
Kapitel 4: Vorlesung OTM – 10Objektverwaltung höherer Ordnung (OHO) – SS 2003
OTS — ÜbersichtObjekt, das an Transaktionteilnimmt, aber selbst keineRessourcen verwaltet, d.h.
keinen expliziten Zustand besitzt
Objekt, das an Transaktionteilnimmt und gleichzeitig einen expliziten Zustandbesitzt (via Ressource)
Objekt, das dieTransaktion initiiert
Transaktions-Kontext
Transaktions-Kontext
OTSTransaktions-
Kontext
Trans-aktionaler
Server
Recov-erableServer
Tx-KontextTrans-aktionaler
Client
Tx-Kontext
ControlCoordinator
RecoveryCoordinator
Current
Current
ResourceSubTxAware-
Resource
Reg
istri
eren
ein
er2P
C-fä
hige
nR
esso
urce
bei
mC
oord
inat
or
Assoziiert mit Thread Assoziiert mit Thread Assoziiert mit Thread
Transfer mit Request Transfer mit Request
TransactionFactoryControl
Terminator
Current ControlCoordinator
Kapitel 4: Vorlesung OTM – 11Objektverwaltung höherer Ordnung (OHO) – SS 2003
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
Kapitel 4: Vorlesung OTM – 12Objektverwaltung höherer Ordnung (OHO) – SS 2003
IDL des OTS – Allgemeine Deklarationen2PC-Entscheidung:
enum Vote {VoteCommit,VoteRollback,VoteReadOnly
};
Vordefinierte Exceptions (Auszug) :
exception NoTransaction {};exception NotPrepared {};exception Inactive {};...
Status einer Transaktion im OTS:
enum Status {StatusActive, StatusMarkedRollback,StatusCommitted,StatusPrepared,StatusRolledBack,StatusUnknown,StatusNoTransaction,StatusPreparing,StatusCommitting,StatusRollingBack
};
Kapitel 4: Vorlesung OTM – 13Objektverwaltung höherer Ordnung (OHO) – SS 2003
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 (); };
Kapitel 4: Vorlesung OTM – 14Objektverwaltung höherer Ordnung (OHO) – SS 2003
IDL (3) – Terminator, Coordinator
Terminator: unterstützt die Beendigung von Transaktionen (wird verwendet vom Initiator der Transaktion)
interface Terminator { void commit ( in boolean report_heuristics); void rollback (); };
Coordinator: Operationen, die von den Teilnehmern der Transaktion (recoverable Server) verwendet werden (z.B. für das Registrieren von Ressourcen)
interface Coordinator { RecoveryCoordinator register_resource ( in Resource r );
Status get_status ();Status get_parent_status ();Status get_top_level_status ();
...};
Kapitel 4: Vorlesung OTM – 15Objektverwaltung höherer Ordnung (OHO) – SS 2003
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
interface Resource { Vote prepare (); void rollback (); void commit (); };
Kapitel 4: Vorlesung OTM – 16Objektverwaltung höherer Ordnung (OHO) – SS 2003
Beispiel: Transfer (explizite Transaktions-Semantik)void FinanceImpl::Transfer( Bank::AccountID a1,Bank::AccountID a2,
Bank::Money amount,CORBA::Environment &env){try {
CosTransactions::Control c;CosTransactions::Terminator t;
c = TFactory->create(0); // create transaction contextt = c->getTerminator;
// get object references to needed Account objectssource = Bank::Account::_bind(“1001@STUD:Bank_Account_OHO7”);destin = Bank::Account::_bind(“3004@STUD:Bank_Account_OHO7");
// transfer money calling methods of Account objectssource->Debit(amount, c, env);destin->Credit(amount, c, env);
t.commit(true); // commit transaction}catch (...){ // indicate errors to caller by TransferFailed exception
t.rollback();throw Bank::Finance::TransferFailed();
}}
Kapitel 4: Vorlesung OTM – 17Objektverwaltung höherer Ordnung (OHO) – SS 2003
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
interface TransactionalObject { };
Kapitel 4: Vorlesung OTM – 18Objektverwaltung höherer Ordnung (OHO) – SS 2003
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)
interface Account
{readonly attribute AccountID number;readonly attribute float balance;
exception InsufficientBalance {};
void Debit ( in float amount )raises (InsufficientBalance);
void Credit ( in float amount ); };
: COSTransactions::TransactionalObject,COSTransactions::Resource
Kapitel 4: Vorlesung OTM – 19Objektverwaltung höherer Ordnung (OHO) – SS 2003
Code-Beispiel Transfer() mit OTS (Current)void FinanceImpl::Transfer(Bank::AccountID a1,Bank::AccountID a2,
Bank::Money amount,CORBA::Environment &env){
try{
Current.begin(); // start new transaction
// get object references to needed Account objectssource = Bank::Account::_bind(“1001@STUD:Bank_Account_OHO7”);destin = Bank::Account::_bind(“3004@STUD:Bank_Account_OHO7");// transfer money calling methods of Account objectssource->Debit(amount, env);destin->Credit(amount, env);
// commit transactionCurrent.commit(true);
}catch (...){ // indicate errors to caller by TransferFailed exception
Current.rollback();throw Bank::Finance::TransferFailed();
}}
Kapitel 4: Vorlesung OTM – 20Objektverwaltung höherer Ordnung (OHO) – SS 2003
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?
Kapitel 4: Vorlesung OTM – 21Objektverwaltung höherer Ordnung (OHO) – SS 2003
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)
Kapitel 4: Vorlesung OTM – 22Objektverwaltung höherer Ordnung (OHO) – SS 2003
… Container, Deployment und Interception
2PC
Container
ServerC
Client
ServerB
Deployment Descriptor
Transaction Required Deployment Descriptor
TransactionSupportedServer
A�
Tx-Kontext
�
Deployment Descriptor
Transaction Not Supported
Kapitel 4: Vorlesung OTM – 23Objektverwaltung höherer Ordnung (OHO) – SS 2003
Container - Standarddienste
Lebenszyklus• Verwaltung des Objektinstanz-Lebenszyklus (Erzeugung, Aktivierung,
...)
Sicherheit• Vergabe und Verwaltung von Zugriffsberechtigungen
Transaktionen• Unterstützung von Transaktionen über mehrere Methodenaufrufe
hinweg
Connection Pooling
Object Pooling
Siehe auch: Enterprise Java Beans
Kapitel 4: Vorlesung OTM – 24Objektverwaltung höherer Ordnung (OHO) – SS 2003
Deployment
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• …
Idee: Container-Programm implementiert derartige Standarddienste / Eigenschaften
Kapitel 4: Vorlesung OTM – 25Objektverwaltung höherer Ordnung (OHO) – SS 2003
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
Kapitel 4: Vorlesung OTM – 26Objektverwaltung höherer Ordnung (OHO) – SS 2003
Transaktionen als StandarddienstTransaction Services:• Transaktionsprimitive (Commit, Abort)• Objektkontexte• Anbindung an Resource-Manager (Datenbanken)
bspw. via XA auch an Oracle• 2PC-Koordination für verteilte Transaktionen
Objektkontext für transaktionelle Objekte • transparent vom Container verwaltet mittels Interception
(s.f. Folie)• speichert Transaktionszustand eines Objektes• Subtransaktionen erben den Kontext der
Vatertransaktion
Kapitel 4: Vorlesung OTM – 27Objektverwaltung höherer Ordnung (OHO) – SS 2003
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.
• Voraussetzung für just-in-time Objekterzeugung