Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort zur 6. Auflage
1 Allgemeine Einführung in .NET
2 Grundlagen der Sprache C#
3 Das Klassendesign
4 Vererbung, Polymorphie und Interfaces
5 Delegates und Ereignisse
6 Strukturen und Enumerationen
7 Fehlerbehandlung und Debugging
8 Auflistungsklassen (Collections)
9 Generics – Generische Datentypen
10 Weitere C#-Sprachfeatures
11 LINQ
12 Arbeiten mit Dateien und Streams
13 Binäre Serialisierung
14 XML
15 Multithreading und die Task Parallel Library (TPL)
16 Einige wichtige .NET-Klassen
17 Projektmanagement und Visual Studio 2012
18 Einführung in die WPF und XAML
19 WPF-Layout-Container
20 Fenster in der WPF
21 WPF-Steuerelemente
22 Elementbindungen
23 Konzepte von WPF
24 Datenbindung
25 Weitere Möglichkeiten der Datenbindung
26 Dependency Properties
27 Ereignisse in der WPF
28 WPF-Commands
29 Benutzerdefinierte Controls
30 2D-Grafik
31 ADO.NET – Verbindungsorientierte Objekte
32 ADO.NET – Das Command-Objekt
33 ADO.NET – Der SqlDataAdapter
34 ADO.NET – Daten im lokalen Speicher
35 ADO.NET – Aktualisieren der Datenbank
36 Stark typisierte DataSets
37 Einführung in das ADO.NET Entity Framework
38 Datenabfragen des Entity Data Models (EDM)
39 Entitätsaktualisierung und Zustandsverwaltung
40 Konflikte behandeln
41 Plain Old CLR Objects (POCOs)
Stichwort

Download:
- Beispiele, ca. 62,4 MB

Buch bestellen
Ihre Meinung?

Spacer
Visual C# 2012 von Andreas Kühnel
Das umfassende Handbuch
Buch: Visual C# 2012

Visual C# 2012
Rheinwerk Computing
1402 S., 6., aktualisierte und erweiterte Auflage 2013, geb., mit DVD
49,90 Euro, ISBN 978-3-8362-1997-6
Pfeil 40 Konflikte behandeln
Pfeil 40.1 Allgemeine Betrachtungen
Pfeil 40.1.1 Das pessimistische Sperren
Pfeil 40.1.2 Das optimistische Sperren
Pfeil 40.2 Konkurrierende Zugriffe mit dem Entity Framework
Pfeil 40.2.1 Das Standardverhalten des Entity Frameworks
Pfeil 40.2.2 Das Aktualisierungsverhalten mit »Fixed« beeinflussen
Pfeil 40.2.3 Auf die Ausnahme »OptimisticConcurrencyException« reagieren
Pfeil 40.2.4 Das »ClientWins«-Szenario
Pfeil 40.2.5 Das »StoreWins«-Szenario

40 Konflikte behandelnZur nächsten Überschrift

Konflikte sind das Grauen aller Softwareentwickler. Sie treten auch in unserem Alltag auf, obwohl wir diese Situationen nicht unbedingt als Konflikt ansehen. Nehmen wir beispielsweise an, Sie möchten über das Internet eine Reise buchen und haben bereits eine passende bei einem Anbieter gefunden. Allerdings vergeht eine mehr oder weniger lange Zeit zwischen dem Finden der Reise und Ihrer Entscheidung, diese zu buchen. Nun könnte es bei dem Versuch der Buchung passieren, dass ein anderer Interessent Ihnen die gewählte Reise regelrecht vor der Nase weggeschnappt hat. Das war, im Datenbankjargon, ein Konflikt, der allerdings nicht von der Software behandelt werden muss und schlicht und ergreifend der Rubrik »Pech gehabt« zugeordnet werden kann.

Konflikte treten immer dann auf, wenn in verbindungslosen Umgebungen mit Daten gearbeitet wird. Das Entity Framework gehört dazu. In diesem Kapitel wollen wir uns mit der Behandlung von Konflikten innerhalb des ADO.NET Entity Frameworks beschäftigen und erläutern, welche Möglichkeiten wir beim Auftreten von Konflikten haben, um auf diese zu reagieren.


Galileo Computing - Zum Seitenanfang

40.1 Allgemeine BetrachtungenZur nächsten ÜberschriftZur vorigen Überschrift

Was ist überhaupt ein Konflikt? Stellen wir uns zur Beantwortung dieser Frage das folgende Szenario vor. In einem Unternehmen arbeiten mehrere Mitarbeiter mit einer Software, die auf eine Datenbank zugreift. Die Mitarbeiter sollen die Datenbank pflegen, also bestehende Datensätze ändern und ergänzen, andere löschen. Nicht selten kann es dabei vorkommen, dass ein Mitarbeiter des Unternehmens, nennen wir ihn einfach User1, denselben Datensatz wie User2 bearbeitet. Wenn User2 seine Änderungen in der Datenbank speichert, bevor User1 seine eigenen Änderungen zurückschreibt, wie soll die Anwendung reagieren? Sollen die Änderungen von User2 durch die Änderungen von User1 überschrieben, also ersetzt werden? Oder soll eine Ausnahme User1 darauf aufmerksam machen, dass ein anderer Kollege dieselbe Datenzeile bereits editiert hat?

Die Problematik dürfte grundsätzlich klar sein, ist aber auch nicht neu. Das führte in der Vergangenheit dazu, dass zwei Sperrstrategien entwickelt worden sind:

  • optimistische Sperren
  • pessimistische Sperren

Lassen Sie uns diese beiden Strategien etwas näher betrachten.


Galileo Computing - Zum Seitenanfang

40.1.1 Das pessimistische SperrenZur nächsten ÜberschriftZur vorigen Überschrift

Wenn man sichergehen will, dass eine Änderung nicht zu einem Konflikt führt, ist das exklusive physikalische Sperren der Daten in der Datenbank der sicherste Weg. Solange die Daten bedingt durch ein Änderung gesperrt sind, können andere Benutzer nicht schreibend – und in manchen Fällen auch nicht lesend – darauf zugreifen. Niemand kann die Daten ändern, bis die Sperre aufgehoben wird. Dieses Verhalten wird als pessimistisches Sperren bezeichnet.

Der Vorteil des pessimistischen Sperrens ist der garantiert exklusive und problemlose Zugriff eines Users auf Daten. Andererseits werden durch pessimistisches Sperren andere Probleme auftreten, wie beispielsweise eine schlechtere Performance und eine schlechte Skalierbarkeit. Möchte ein anderer User auf gesperrte Daten zugreifen, ist er darauf angewiesen, dass der Benutzer, der die Sperre verursacht hat, möglichst schnell die Sperre wieder aufhebt – die Produktivität sinkt. Stellt man sich zudem vor, dass viele Benutzer gleichzeitig auf die Daten zugreifen wollen, stellt das pessimistische Sperren wegen der schlechten Verfügbarkeit der Daten einen völlig indiskutablen Lösungsansatz dar.


Galileo Computing - Zum Seitenanfang

40.1.2 Das optimistische SperrenZur vorigen Überschrift

Pessimistisches Sperren hat Vor- und Nachteile. Oftmals wiegen die Nachteile stärker als die Vorteile. Das optimistische Sperren, ein gänzlich anderer Lösungsansatz, geht die Problematik anders an: Dabei spielt die Idee, dass der gleichzeitige schreibende Datenzugriff nicht sehr häufig auftritt, die tragende Rolle. Werden Daten nicht sehr häufig geändert und ist die Wahrscheinlichkeit, dass dieselben Daten quasi parallel geändert werden, nicht sehr hoch, dann müssen die Daten tatsächlich nur in dem Moment gesperrt werden, wenn der schreibende Zugriff erfolgt.

Optimistische Sperren erhöhen die Produktivität durch Verbesserung der Performance einer Anwendung, da allen Benutzern gleichermaßen das Recht eingeräumt wird, Daten zu lesen und zu ändern. Allerdings muss beim Zurückschreiben geänderter Daten geprüft werden, ob sich der Datensatz seit dem Lesevorgang verändert hat. Die beste Lösung ist in solchen Fällen, eine Spalte zu einer Tabelle hinzuzufügen, deren Wert sich mit jeder Änderung an der Datenzeile ebenfalls ändert und somit gewissermaßen eine Art Versionierung darstellt. In einer Umgebung mit mehreren Benutzern wird der erste Benutzer seine Änderung problemlos in die Datenbank schreiben können, alle anderen danach werden bei dem Versuch scheitern.

Der SQL Server verwendet für die Versionierung Timestamp-Spalten (bzw. RowVersion-Spalten), deren Wert sich bei jedem Einfüge- oder Aktualisierungsvorgang automatisch verändert. Um festzustellen, ob sich seit dem Lesevorgang eine Datenzeile geändert hat, muss der Wert der Timestamp-Spalte, der beim Lesen der Datenzeile aktuell war, zusammen mit dem Primärschlüssel in die WHERE-Klausel aufgenommen werden, z. B.:

UPDATE ... SET ... WHERE ID = ... AND VersionColumn = ...

Kann die Datenzeile nicht aktualisiert werden, weil sich in der Zwischenzeit der Wert der Timestamp-Spalte geändert hat, liegt ein Parallelitätskonflikt vor.

Nicht jede Tabelle hat eine Timestamp-Spalte. In solchen Fällen bleibt nichts anderes übrig, als die Spalten, die als konfliktverursachend angesehen werden, in die WHERE-Klausel mit aufzunehmen.

Optimistisches Sperren sichert einer Anwendung hohe Verfügbarkeit und Skalierbarkeit. Allerdings kaufen wir uns diese Vorteile nur durch einen höheren Programmieraufwand ein, da wir bei einem auftretenden Konflikt in der Regel darauf reagieren müssen, weil beispielsweise die neuen aktuellen Daten aus der Datenbank gelesen werden müssen.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
  Zum Katalog
Zum Katalog: Visual C# 2012

Visual C# 2012
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Professionell entwickeln mit Visual C# 2012






 Professionell
 entwickeln mit
 Visual C# 2012


Zum Katalog: Windows Presentation Foundation






 Windows Presentation
 Foundation


Zum Katalog: Schrödinger programmiert C++






 Schrödinger
 programmiert C++


Zum Katalog: C++ Handbuch






 C++ Handbuch


Zum Katalog: C/C++






 C/C++


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo





Copyright © Rheinwerk Verlag GmbH 2013
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Rheinwerk Computing]

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de