Am 14. September 2017 haben wir eine überarbeitete Fassung unserer Datenschutzrichtlinie veröffentlicht. Wenn Sie video2brain.com weiterhin nutzen, erklären Sie sich mit diesem überarbeiteten Dokument einverstanden. Bitte lesen Sie es deshalb sorgfältig durch.

Java EE 7: Geschäftsanwendungen

Entitäten sperren

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Bei verteilten Applikationen kann es vorkommen, dass Benutzer zeitgleich Änderungen an Datensätzen vornehmen wollen. Dafür stehen unterschiedliche Sperrmechanismen zur Verfügung: Implementieren Sie hier eine optimistische Sperrung auf Ebene der Entitäten.

Transkript

Datensätze können in Java-EE-Applikationen von mehreren Benutzern parallel bearbeitet werden. Das ist ein übliches Vorgehen, beziehungsweise ein übliches Ergebnis dessen, das wir die Applikation, ja, als Webapplikation veröffentlichen wollen. Aus diesem Grund, muss es Mechanismen geben mit deren Hilfe man Datensätze sperren kann. Und in diesem Video werden wir uns genau damit auseinandersetzen, nämlich welche Arten der Sperrung von Datensätze es gibt und wie wir diese Sperrungen nutzen können. General ist es so, dass die JPA zwei Arten des Sperrens von Datensätzen unterstützt: die optimistische Sperrung und die pessimistische Sperrung. Die optimistische Sperrung ist der Standard und die pessimistische Sperrung gibt es erst seit der JPA Version 2.0. Die pessimistische Sperrung kostet dabei deutlich mehr Performance, als die optimistische Sperrung, auf der anderen Seite ist sie deutlich sicherer als die optimistische Sperrung. Warum? Das werden wir gleich besprechen. Die optimistische Sperrung ist eigentlich gar keine Sperrung, wenn man es genau nimmt, sie ist nämlich lediglich ein zusätzliches Feld, was auf einen Datensatz mitgeführt wird und was automatisch mit Inhalten befüllt wird. Damit dieses Feld als solches erkannt werden kann, müssen wir darüber die Version-Annotation schreiben und dann kann das Feld, wenn es den erlaubten Datentypen "int, short, long oder java.sql.Timestamp" entspricht automatisch mit Inhalten befüllt werden. Der Datensatz kann jeder Zeit gelesen und verändert werden. Und was im Grunde passiert ist, dass wenn wir ein Datensatz updaten oder löschen wollen, der Wert, der in diesem Versionsfeld drin steht automatisch mit in die Abfrage aufgenommen wird. Das heißt, beim Commit der Transaktion wird dann eben eine entsprechende Bedingung mitformuliert. Wenn das Datenbanksystem nun zurückgibt, dass es keine Datensätze geändert oder betroffen gefunden hat, dann gibt es eine Exception, weil dann stimmte die Version nicht mehr überein, mit dem, was in der Datenbank steht. Stren genommen ist die optimistische Sperrung also keine Sperrung im engeren Sinne, denn sie findet nur auf Applikationsebene statt. Wenn parallel jemand anderes den Datensatz mit einem Datenbank Management Tool beispielsweise, oder eine andere Applikation bearbeitet, dann bekommen wir das überhaupt nicht mit solange, wie sich das Versionsfeld nicht ändert. Anders er gegen die pessimistische Sperrung. Bei der pessimistischen Sperrung ist es so, dass der Datensatz exklusiv gesperrt ist, und zwar auf Ebene der Datenbank. Das bedeutet, dass je nach dem welche Art der Sperrung wir unterstützen, der Datensatz zwar noch gelesen werden kann, aber eben nicht mehr bearbeitet werden kann. Bei jedem Versuch der Bearbeitung eines pessimistisch gesperrten Datensatzes, wird das Datenbanksystem seinerseits schon ein Fehler werfen. Das Ganze muss allerdings aktiviert werden und die Aktivierung kann auf verschiedene Arten und Weisen passieren. Zum einen gibt es bei der find()-Methode des EntityManagers die Möglichkeit einen sogenannten lock()-Mode anzugeben. Genau dasselbe macht die lock()-Methode eines EntityManagers, der wie eine Instanz einer Entität einfach übergeben und dann halt sagen, wie soll das ganze Ding gesperrt werden. Und die dritte Variante ist, wenn wir Abfragen benutzen, dass wir dort ein zusätzliches Attribut mitangeben, nämlich lockMode, und dieses Attribut wird dann bei jeder Abfrage mit Hilfe dieser Abfrage, mit übergebend und angewandt. Auf Applikationsebene ist es wichtig sich für eine Art des Lockings oder für die beste Art des Lockings zu entscheiden. Welche das ist, hängt natürlich immer vom Szenario ab. In unserer Applikation werden wir uns für das optimistische Locking entscheiden. Wir möchten sicherstellen, dass der Custmor Datensatz samt seiner abhängigen Daten nur bearbeitet werden kann, wenn er noch die exakt selbe Version beim Laden hat. Dies werden wir uns nun umsetzen. Hier auf Ebene der Customer-Klasse werden wir nun ein Feld einfügen, das als Versionsinformation dient. So ein Versionsfeld ist üblicherweise halt ein privates Feld. Wir können die Version, die bereits erwähnt, als nummerischen Wert oder als java-sql-Timestamp angeben. Wir entscheiden uns hier für den Timestamp, müssen natürlich den richtigen Timestamp aus dem richtigen Package nehmen und wie das Feld heißt ist relativ egal. Wir werden es "lastChanged" nennen. Damit dieses Feld als Versionsfeld erkannt wird, annotieren wir es einfach nur mit der Version-Annotation. Wir werden hier an der Stelle keine weitere Änderung an dieser Klasse vornehmen, bedeutet, wir werden nicht hingehen und dieses Feld über ein Getter und ein Setter zur Verfügung stellen, das ist nicht nötig, könnte man natürlich machen, aber es ist nicht nötig für unser Szenario. Wir wollen einfach nur sicherstellen, dass halt die entsprechende Information über die letzte Änderung in der Datenbank automatisch gespeichert und beim Updaten, beziehungsweise Löschen eines Datensatzes mitherangezogen wird. Dasselbe wählen wir nun auf Ebene der Address-Entität machen und hier machen wir es uns ganz einfach, wir kopieren das Feld einfach mithinein und das Gleiche dann auch nochmal bei der Communication-Entität. Damit haben alle drei Entitäten mit einem optimistischen Lockingansatz versehen und können nun einigermaßen sicher sein, dass Benutzer unserer Applikation parallel zwar Daten einsehen können, aber parallele Änderungen, beziehungsweise konkurrierende Änderungen automatisch erkannt werden und im Zweifelsfall mit einer Exception beantwortet werden, was vielleicht für den jeweiligen Nutzer nicht sonderlich angenehm ist, aber im Sinne von Datenintegrität und Datensicherheit natürlich schon ein gewaltiger Vorteil ist. Aber biite vergessen Sie nicht den Nachteil. Das Ganze kann direkt auf der Datenbankebene jederzeit umgangen werden. In diesem Video haben wir uns mit den beiden Möglichkeiten des Lokings, also pessimistisch, beziehungsweise optimistisch auseinandergesetzt. Und wir haben den optimistischen LockMode in unseren Entitäten integriert.

Java EE 7: Geschäftsanwendungen

Verfolgen Sie, wie eine komplette Business-Applikation unter dem Einsatz des gesamten Java-Enterprise-Techologiestacks ensteht.

5 Std. 2 min (39 Videos)
Derzeit sind keine Feedbacks vorhanden...
 

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!