3.3 Objekt-Transaktions-Monitore (OTM) - dbs.ethz.ch · PDF fileObjektverwaltung höherer...

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


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


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


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


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)


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


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:


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


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


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


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


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

};


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 (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 ();

...};


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 (); };


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();

}}


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 { };


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


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();

}}


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)


… Container, Deployment und Interception

2PC

Container

ServerC

Client

ServerB

Deployment Descriptor

Transaction Required Deployment Descriptor

TransactionSupportedServer

A�

Tx-Kontext

�

Deployment Descriptor

Transaction Not Supported


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


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


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


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


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

3.3 Objekt-Transaktions-Monitore (OTM) - dbs.ethz.ch · PDF fileObjektverwaltung höherer...

Documents

Transcript of 3.3 Objekt-Transaktions-Monitore (OTM) - dbs.ethz.ch · PDF fileObjektverwaltung höherer...