Enterprise JavaBeans Überblick

Transkript

1 Enterprise JavaBeans Überblick 1. Überblick Komponententechnologien 2. Einführung 3. Enterprise JavaBeans Architektur 4. Ressourcen Management und Primäre Services 5. Java Persistence: Entity Manager 6. Objekt-Relationales Mapping 7. Entity Bean Beziehungen 8. Test-Driven Development 9. Architektur der Web-Schicht 10. Queries 11. Value Objects 12. Session Facade 14. Ergänzungen zu Entity Beans UML Modellierung und EJBs 16. Session Beans Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 404 Enterprise JavaBeans Überblick: 13.4 Guidelines Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 405

2 Grundzüge schon bekannt aus (oder kommen noch einmal im) Seminarvortrag Transaktionen ACID Eigenschaften Atomic Ausführung komplett in allen Bestandteilen erfolgreich oder überhaupt nicht Consistent Konsistenter Zustand des zugrunde liegenden Systems vorher und nachher Betrifft meist die Datenspeicherung in einer Datenbank Isolated Keine Beeinflussung durch andere Prozesse oder Transaktionen Mehrere Transaktionen werden nacheinander durchgeführt Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 406 ACID Eigenschaften (fortgesetzt) Durable Bei Erfolg (Commit) werden Daten in einen persistenten Speicher geschrieben Überleben dort Hardware- und Software-Fehler Können ggf. aus Transaktions-Logs rekonstruiert werden Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 407

3 Java Transaction Service (JTS) Low-level API der Java EE-Spezifikation Hauptsächlich für Application Server Provider Ist die Java Implementierung des OMG CORBA Object Transaction Service (OTS) Transaktionsunterstützung auch für den Fall, wenn mehrere Parteien bei der Transaktion beteiligt sind Erlaubt es, einen Transaktions-Kontext an mehrere Server weiter zu geben: Verteilte Transaktionen Nicht für EJB Entwickler Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 408 Java Transaction Service (JTS) (fortgesetzt) Realisiert durch 2 Haupttypen von Locks Read Locks Nicht-exklusiv mehrere Transaktionen können denselben Lock gleichzeitig halten Write Locks Exklusiv Nur eine Transaktionen kann denselben Lock zu einer Zeit halten Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 409

4 Transaktionsunterstützung in Java EE Leicht zu benutzen Grundlegende Begriffe Resource Persistenter Speicher, in den geschrieben werden kann Datenbank, JMS Queue, JCA Connector,... Resource Manager Sind für Resource verantwortlich Datenbank Management System, Message Provider Produkt Transactional Object Die Komponente, die in der Transaktion beteiligt ist z.b. eine Session Bean, die die Transaktion durchführt Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 410 Transaktionsunterstützung in Java EE Grundlegende Begriffe (fortgesetzt) Transaction Manager Komponente oder System, verantwortlich, die Operationen der Transaktion von Transaktions-Komponenten durchzuführen JBoss ist ein Transaction Manager Verwendet eine Anwendung mehr als einen Resource Manager in einer Transaktion, dann benötigt man einen externen Transaction Manager Auch das kann JBoss sein Beispiel: Lesen aus einer Message Queue, schreiben in einen Datenbank, beides in einer Transaktion Verteilte, globale Transaktion Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 411

5 XA-Protokoll Standard-Interface zwischen Transaction Manager und Resource Manager Transaction Manager koordiniert die verteilte Transaktion Verwendet das XA-Protokoll, um mit Datenbank-Backends zu kommunizieren Datenbank muss XA-Protokoll verstehen, um verteilte Transaktionen unterstützen zu können Transaction Manager kommuniziert über XA-Protokoll mit Resource Managers Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 412 Two-pase commit Phase eins Preparations-Phase Prüfe Status jedes Resource Managers, ob sie ready to commit the transaction sind Alle müssen zustimmen Phase zwei Commit-Phase Alle haben in Phase eins zugestimmt Alle Resource Managers werden instruiert, commit durchzuführen Wenigstens einer hat nicht zugestimmt Alle Resource Managers werden instruiert, einen roll-back durchzuführen Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 413

6 Lokale Transaktion Nur ein Resource Manager ist involviert Mehrere Tabellen in 1 Datenbank Resource Manager des Datenbank kümmert sich darum Globale Transaktion Mehr als ein Resource Manager ist involviert Es wird ein globaler Transaction Manager zur Steuerung der verteilten Transaktion benötigt Verwendet Two-phase Commit Protokoll Resource Managers müssen XA-Protokoll unterstützen Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 414 Container Managed Transactions Nicht im Code sichtbar Container startet Transaktion, setzt sie fort, suspendiert sie, ignoriert sie oder beendet sie. Deklarative Steuerung durch Transaktions-Attribute Start mit Beginn einer Methode Endet frühestens mit Beendigung der Methode Benachrichtigung des Containers über Misserfolg setrollbackonly() Methode des EJBContext Werfen einer EJBException Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 415

7 Transaktionsattribute Transaktionsattribut NotSupported Required (default) Supports RequiresNew Mandatory Never Klient / andere Bean keine T1 keine T1 keine T1 keine T1 keine T1 keine T1 Transaktion der Bean Methode keine keine T2 T1 keine T1 T2 T2 Fehler T1 keine Fehler Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 416 Transaktionsattribute: Regeln Session Beans Für alle Geschäftsmethoden Entity Beans Nicht anwendbar Message-driven Beans Nur für die onmessage() Methode Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 417

8 Enterprise JavaBeans Überblick: 13.4 Guidelines Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 418 In welcher Hinsicht kann innerhalb einer Transaktion etwas schief gehen? Dirty read Lesen von Daten, die noch nicht committed wurden A modifiziert einen Satz B liest ihn bevor A committed A führt ein rollback durch B hat Daten gelesen, die es nie gegeben hat Non-repeatable read Daten wurden zwischen zwei Leseoperationen desselben Satzes verändert (zu fein-granulare Locks) A liest Satz, ohne commit; gibt Lock frei B modifiziert oder löscht denselben Satz und committed A setzt Bearbeitung fort und liest denselben Satz noch einmal Änderung oder existiert nicht mehr Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 419

9 In welcher Hinsicht kann innerhalb einer Transaktion etwas schief gehen? (fortgesetzt) Phantom read Neue Daten wurden zwischen zwei Leseoperationen einer Menge von Sätzen eingefügt A liest über eine Suche eine Menge von Sätzen, committed nicht B fügt einen oder mehrere Sätze hinzu, die die Suchbedingung erfüllen und committed A setzt die Bearbeitung fort, wiederholt den Lesevorgang unter derselben Suchbedingung und findet neue Sätze Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 420 Datenbank Locking-Strategien Read Locks Daten, die gelesen wurden, können nicht geändert werden, bevor die Transaktion abgeschlossen ist Keine non-repeatable Reads Write Locks Verwendet bei Updates. Verhindert das Ändern der Daten bevor die Transaktion abgeschlossen ist Erlaubt aber dirty reads Exclusive Write Locks Verwendt bei Updates. Verhindert das Lesen oder Ändern der Daten bevor die Transaktion abgeschlossen ist Verhindert dirty reads Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 421

10 Datenbank Locking-Strategien (fortgesetzt) Snapshots Schnappschuss eines eingefrorenen Views auf die Daten Verhindert dirty reads, non-repeatable reads und phantom reads Aber die Daten können nicht mehr aktuell sein Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 422 Isolation Levels Gelten nur für JDBC-Datenbanken Bestimmte Locking Strategien, um die o.g. Probleme zu beheben Können EJBs zugewiesen werden wie Transaktionsattribute der Bean als Default individuell für Methoden Sind Teil der sog. access-intent Strategie für EJBs Isolation Levels sind nicht Bestandteil der J2EE 1.3 Spezifikation Application Server spezifisch Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 423

11 4 Isolation Levels Read uncommitted Schwächste Isolation Alle obigen Probleme können auftreten, unabhängig von dem Isolation Level der anderen Transaktion Nicht für kritische Anwendungen einsetzen! Gute Performanz Read committed Nur committed Daten werden gelesen Keine dirty reads Non-repeatable reads und phantom reads können auftreten Gelesenen Daten sind immer konsistent Anwendung: Generieren von Berichten Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans Isolation Levels (fortgesetzt) Repeatable read Mehrfaches Lesen in derselben Transaktion liefert dieselben Daten Keine dirty reads oder non-repeatable reads Nützlich bei häufigen Updates Andere Transaktionen können unsere Daten nicht modifizieren Phantom reads können noch vorkommen Serializable Stärkste Isolation Alle ACID Eigenschaften werden eingehalten Alle Transaktionen sind voneinander unabhängig, werden nacheinander ausgeführt Für kritische Anwendungen Performanz kann schlecht werden Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 425

12 Enterprise JavaBeans Überblick: 13.4 Guidelines Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 426 Mögliche Probleme Ändern des Default-Verhaltens bei CMP funktioniert nicht (EJB 2.1) Änderung geht, aber Laufzeitverhalten wird durch strenges Locking zu negativ beeinflusst Transaktion mit hohem Isolation Level verbietet sich aufgrund von Denkzeit des Benutzers Lesen der Daten Denkzeit Update der Daten Sind Daten dann noch aktuell oder wurden Sie in einer anderen Transaktion bereits verändert? Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 427

13 Beispiel: Message Board Administration Moderator A liest Message X in einer Transaktion Moderator B liest Message X in einer Transaktion Moderator A editiert seine Kopie der Message lokal Moderator B editiert seine Kopie der Message lokal Moderator A schreibt Message in einer Transaktion zurück Moderator B schreibt Message in einer Transaktion zurück Alle Änderungen von Moderator A sind verloren Moderator B hat nicht mehr gültige Daten verändert Repräsentieren nicht mehr den aktuellen Zustand der Entity Bean Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 428 Optimistische Concurrency Control In EJB 3.0 erstmals sauber spezifiziert Bei Update Vergleich mit Zustand beim Lesen Statt alle Felder zu vergleichen zusätzliches Versionsfeld in jeder Tabelle Wird bei jedem Update automatisch inkrementiert Modifizierte Where-Klausel bei Update: Primärschlüssel und alter Wert des Versionszählers Durch EntityManager realisiert Repräsentiert den sich über die Zeit wandelnden Zustand der Entity Bean Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 429

14 Versionszähler Beispiel: Klasse zur Reservierung einer Cabin in einem Cruise Eins-zu-eins Beziehung zu public class CruiseCabin { private int id; private Cabin cabin; private Cruise cruise; private boolean isreserved; private long protected long getversion() { return version; } protected void setversion(long version) { this.version = version; } } Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 430 Versionszähler Mögliche Datentypen int, Integer short, Short long, Long Timestamp Wird bei jedem Update von dem Persistence Framework inkrementiert Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 431

15 Versionszähler Vor einem Commit mit einer veränderten Entity Bean wird zunächst geprüft, ob die Entity Bean im Speicher dieselbe Version wie der entsprechende Satz in der Datenbanktabelle besitzt Falls ja EntityManager führt Commit durch Inkrementiert Versionszähler Falls nein EntityManager wirft Exception Führt Rollback durch Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans Umsetzung in EJB 3.0 Beispiel Client-Code public Reservation bookpassage(string card, double price) throws IncompleteConversationalState ( if (customer == null cruise == null cabin == null) throw new IncompleteConversationelState(); try { Query query = entitymanager.createquery( "SELECT cc FROM CruisCabin cc WHERE " + "cc.cabin = :cabin AND cc.cruise = :cruise"); query.setparameter("cabin", cabin); query.setparameter("cruise", cruise); CruiseCabin cc = (CruiseCabin) query.getsingleresult(); if (cc.getisreserved()) throw new EJBException("Cabin is already reserved for cruise!"); cc.setisreserved(true);... Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 433

16 Beispiel Client-Code (fortgesetzt)... cc.setisreserved(true); Reservation reservation = new Reservation(customer, cruise, cabin, price, new Date()); entitymanager.persist(reservation); process.bycredit(customer, card, price); return reservation; } catch (Exception ex) { throw new EJBException(ex); } } Bei Versionsfehler javax.persistence.optimisticlockexception Rollback Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 434 Realisierung SQL-Anweisung UPDATE CRUISE_CABIN SET isreserved=true, version=version+1 WHERE id=1 AND version=101; Dabei kurzzeitiger Write-Lock für diesen Satz Besser als globaler Table Lock bei stärkster Isolation (Serializable) Fehler, falls Anzahl modifizierter Sätze = 0 Optimistisches Locking nicht passend bei hoher Rate paralleler Schreibzugriffe Hohe Anzahl von Rollbacks Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 435

17 Explizites Locking Methode lock() des EntityManagers entitymanager.lock(cabin, LockModeType.WRITE); Semantik der beiden Typen LockModeType.READ und LockModeType.WRITE: Transaktion T1 ruft lock(entity, LockModeType.READ) für ein versioniertes Objekt auf Dann stellt der EntityManager sicher, dass die folgenden Phänomene nicht auftreten können:... Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 436 Explizites Locking mit LockModeType.READ verhindert P1 (Dirty read): Transaktion T1 modifiziert eine Satz Transaktion T2 liest diesen Satz und erhält den modifizierten Wert, bevor T1 Commit oder Rollback aufgerufen hat Transaktion T2 committed irgendwann erfolgreich; es ist egal, ob T1 committed oder zurückrollt und ob das vor oder nach dem Commit von T2 geschieht P2 (Non-repeatable read): Transaktion T1 liest einen Satz Eine andere Transaktion T2 modifiziert oder löscht diesen Satz danach, jedoch bevor T1 committed Beide Transaktionen schließen irgendwann erfolgreich mit Commit ab Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 437

18 Explizites Locking Beide Lock Modes verhindern diese Phänomene P1 and P2 LockModeType.WRITE bei einem versionierten Objekt erzwingt zusätzlich ein Update (increment) für die Version Spalte Die Persistenz Implementierung muss EntityManager.lock() für nichtversionierte Objekte nicht unterstützen. Falls es das nicht unterstützt, muss es eine PersistenceException werfen Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 438 Enterprise JavaBeans Überblick: 13.4 Guidelines Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 439

19 Guidelines für Transaktionen Verwende kurze Transaktions-Zyklen Denkzeit des Benutzers sollte darin nicht vorkommen Session Facade Pattern unterstützt dies gut Default Wahl für das Transaktionsattribut sollte Required sein RequiresNew ist nützlich, wenn eine Bean-Methode unabhängig von anderen Transaktionen seine Transaktion (erfolgreich oder nicht erfolgreich) beenden sollte Session Beans, die das Interface SessionSynchronization implementieren, müssen eines der Transaktionsattribute Required, RequiresNew oder Mandatory besitzen Vermeide die Transaktionsattribute Supports und NotSupported Methoden laufen unter einem unspecified transaction context Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans Guidelines Guidelines für Anwendungs-Transaktionen Anwendungs-Beans sollten einen Rollback explizit auslösen EJBContext.setRollbackOnly() Eine Application Exception bewirkt kein Rollback durch den Container Anwendungs-Beans können überprüfen, ob von ihnen aufgerufenen Beans Rollback gesetzt haben EJBContext.getRollbackOnly() Sich nicht auf Exception verlassen setrollbackonly() kann aufgerufen werden, ohne eine Exception werfen zu müssen (sollte man aber nicht tun) Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 441

20 13.4 Guidelines Guidelines für Anwendungs-Transaktionen (fortgesetzt) Liefert ein Aufruf zu einer anderen Bean eine RemoteException: Hat die Bean ein Rollback veranlasst? Wurde sie überhaupt aufgerufen Dann besser: EJBContext.setRollbackOnly() aufrufen Geeignete Application Exception oder RemoteException werfen Nächste Ebene soll entscheiden, was zu tun ist! Will eine Bean ihr Transaktion unabhängig von dem Resultat einer aufgerufenen Bean behandeln Die andere Bean sollte RequiresNew oder NotSupported verwenden Kann aber zu Deadlock führen, wenn beide Transaktionen dieselbe Ressource verwenden wollen Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans Guidelines Guidelines für Anwendungs-Transaktionen (fortgesetzt) Hat man in einer Anwendungs-Bean Probleme mit Transaktions- Grenzen, so kann man Bean-managed Transaktionen einsetzen So kann man kleinteiligere Transaktionen erreichen Auch wenn viele Bücher das als schlecht hinstellen Prof. Dr. Björn Dreher Liste V Enterprise JavaBeans 443