Pflichtenheft - Berner Fachhochschule

Pflichtenheft Diplomarbeit
Nr. MAS-06-01.15
Grafischer Transaktionssimulator
MAS-IT-06-01, 22. April 2008
Abstract
Der Transaktionssimulator simuliert Datenbank-Benutzer, und lässt diese in
gegenseitiger Konkurrenz auf eine reale Datenbank zugreifen. Simulationen sind
parametrisierbar: Anzahl gelesener und geschriebener Datensätze, Isolationsgrad,
Häufigkeit und Nebenläufigkeit der User usw. sind einstellbar. Gemessen werden
u.a. Anzahl Trans-aktionen, Phantoms, Deadlocks und Lost Updates. Die
Parametereingabe und Resultdarstellung erfolgt im GUI. Simulationsmodelle werden
in XML erfasst.
Schlüsselwörter
Simulation, Transaktion, Datenbank
Autor:
Paul Klarenberg
Sandrainstrasse 60a
3007 Bern
+41 31 372 92 82
Betreuer:
Dr. Arno Schmidhauser
Wankdorffeldstrasse 102
Postfach 325
CH-3000 Bern 22
+41 31 84 83 275
Experte:
Max Kleiner
Kasernenstrasse 41
3001 Bern
Versionskontrolle
Datum
Version
Autor
Beschreibung
2008-04-06
0.1
P. Klarenberg
Initialversion
2008-04-21
1.0
P. Klarenberg
Reviews M. Kleiner und A.
Schmidhauser eingepflegt
2008-04-22
1.1
P. Klarenberg
Begriffe SRS und SDD im Glossar
zugefügt
Seite 2 von 23
Inhaltsverzeichnis
1
EINLEITUNG ............................................................................................. 4
1.1
1.2
1.3
1.4
1.5
2
ZWECK DES DOKUMENTS ..................................................................................... 4
ZIEL DES SOFTWAREPRODUKTS ........................................................................... 4
BEGRIFFEN, AKRONYME UND ABKÜRZUNGEN ..................................................... 5
REFERENZEN ........................................................................................................ 7
ÜBERSICHT .......................................................................................................... 7
ALLGEMEINE BESCHREIBUNG................................................................. 8
2.1
PRODUKT PERSPEKTIVE ....................................................................................... 8
2.1.1
SYSTEM SCHNITTSTELLEN ........................................................................... 8
2.1.2
BENUTZER-SCHNITTSTELLEN....................................................................... 8
2.1.3
HARDWARE SCHNITTSTELLEN ..................................................................... 9
2.1.4
SOFTWARE SCHNITTSTELLEN ....................................................................... 9
2.1.5
KOMMUNIKATIONS-SCHNITTSTELLEN ......................................................... 9
2.1.6
SPEICHERBESCHRÄNKUNGEN ....................................................................... 9
2.1.7
BETRIEB ....................................................................................................... 9
2.2
PRODUKTFUNKTIONEN ......................................................................................... 9
2.3
BENUTZERMERKMALE ....................................................................................... 10
2.4
EINSCHRÄNKUNGEN........................................................................................... 10
2.5
ANNAHMEN UND ABHÄNGIGKEITEN .................................................................. 10
2.6
VERSIONIERUNG DER ANFORDERUNGEN............................................................ 10
3
SPEZIFISCHE ANFORDERUNGEN ............................................................ 10
3.1
EXTERNE SCHNITTSTELLEN ............................................................................... 10
3.1.1
ANFORDERUNGEN AN DAS GUI ................................................................. 10
3.1.2
ANFORDERUNGEN AN DIE DATENBANK-SCHNITTSTELLE ........................... 11
3.2
FUNKTIONALE ANFORDERUNGEN ...................................................................... 11
3.2.1
ANFORDERUNGEN AN DEN SIMULATOR ..................................................... 11
3.2.2
ANFORDERUNGEN AN DEN KONFIGURATOR ............................................... 12
3.3
LEISTUNGSANFORDERUNGEN ............................................................................. 13
3.4
DESIGN CONSTRAINTS ....................................................................................... 13
3.5
QUALITÄTSANFORDERUNGEN ............................................................................ 13
3.5.1
ZUVERLÄSSIGKEIT (RELIABILITY) ............................................................. 13
3.5.2
VERFÜGBARKEIT (AVAILABILITY) ............................................................. 13
3.5.3
SICHERHEIT (SECURITY) ............................................................................ 13
3.5.4
WARTBARKEIT (MAINTAINABILITY).......................................................... 13
3.5.5
PORTABILITÄT (PORTABILITY)................................................................... 14
3.6
SONSTIGE ANFORDERUNGEN ............................................................................. 14
3.6.1
SUPPORTABILITY........................................................................................ 14
3.6.2
ONLINE USER DOCUMENTATION AND HELP SYSTEM REQUIREMENTS .......... 14
3.6.3
EINGEKAUFTE KOMPONENTEN................................................................... 14
3.6.4
LIZENZIERUNG ........................................................................................... 14
3.6.5
RECHTLICHES, URHEBERRECHTE AND ANDERE VERMERKE ....................... 14
3.6.6
USABILITY ................................................................................................. 14
3.6.7
ANZUWENDENDEN STANDARDS ................................................................. 14
ANHANG A. FUNKTIONSPRINZIP SIMULATOR ............................................. 15
ANHANG B. LOFI PROTOTYP GUI............................................................... 18
Seite 3 von 23
1 Einleitung
1.1 Zweck des Dokuments
Dieses Dokument spezifiziert die Anforderungen and den Transaktionssimulator. Es
dient als Vereinbarung zwischen dem Kunden (d.h. dem Betreuer dieser
Diplomarbeit) und dem Software-Hersteller (d.h. dem Diplomanden).
1.2 Ziel des Softwareprodukts
Der Transaktionssimulator soll die Performance und das Auftreten möglicher
Inkonsistenzen simulieren, wenn viele Transaktionen gleichzeitig auf eine Datenbank
zugreifen. Diagramm 1 zeigt die Analogie zwischen der Simulation und der
simulierten Wirklichkeit.
Der Transaktionssimulator soll nicht die Mechanismen demonstrieren wonach diese
Inkonsistenzen entstehen, sondern statistische Daten über deren Auftreten erheben
und Visualisieren.
Der Transaktionssimulator soll im Rahmen des Unterrichts des Fachs Datenbanken
eingesetzt werden. Primär vom Dozenten (Frontalunterricht) und möglicherweise
auch von Studenten (Praktikum).
Seite 4 von 23
Diagramm 1: Analogie zwischen Simulation und simulierter Wirklichkeit
1.3 Begriffen, Akronyme und Abkürzungen
Begriff oder Fachklasse
Beschreibung
Application
Der Transaktionssimulator
DBConnection
Die aktuelle Verbinding via JDBC mit einer Datenbank.
DatabaseConnectionProfile
Die produktspezifische Spezifikation für eine DatenbankVerbindung (u.a. User Account Daten, Treiber-Name,
Seite 5 von 23
Begriff oder Fachklasse
Beschreibung
usw.)
Isolation Level / Isolationsgrad
Isolationsgrad gemäss SQL Standard: 0 = read
uncommitted, 1 = read committed, 2 = repeatable read, 3
= serializable
Operation
Primitive Datenbankoperation Read (R), Update (U),
Delete (D) und Insert (I). Werden mit SQL-Befehle
implementiert.
Show
Eine Menge benannte Simulationsmodelle samt
Simulationsparameter welche als ganzes konfiguriert und
geladen werden kann.
Simulation
Das ausgeführte Simulationsmodell (auch:
Simulationslauf).
Simulationsmodell
Ein lauffähiges Modell einer Simulation, bestehende aus
einem oder mehreren Transaktionsmodellen und relativen
Mengen. z.B. "2*RR1 + 1*RU1"
Simulationsparameter
SimulationThread
Ein Thread der, stellvertretend für einen User, gemäss
einem Transaktionsmodell auf die Datenbank zugreift.
Software Design Description
(SDD)
Spezifikation des Software-Designs gemäss IEEE 1016.
Die SDD beschreibt die Lösung, die SRS dagegen die
Anforderungen.
Software Requirements
Specification (SRS)
Spezifikation der Software Anforderungen gemäss IEEE
830. Die SRS beschreibt die Anforderungen, die SDD
dagegen die Lösung.
TransactionModel
Transaktionmodell, welche den Verlauf einer Transaktion
beschreibt. Elemente: Transaktionsmuster und
Transaktionsparameter unf Isolationsgrad.
Transaktionsmuster
Eine Reihe von Operationen (z.B. RR oder RU)
Transaktionsparameter
- Anzahl gelesene Datensätze in Prozent (R%)
- Anzahl geänderte Datensätze in Prozent von R% (U%)
- Absolute Anzahl geänderte Datensätze (I)
- Anzahl der gelöschten datensätze in Prozent (D%)
- Pausezeit (P) vor und zwischen den Operationen
Usage Pattern
User Type
Diagramm 2 zeigt ein Fachklassendiagramm mit den wichtigsten fachlichen Begriffen
und deren Zusammenhänge.
Seite 6 von 23
class Fachklassenmodell Transaktionssimulator
Application
Die Simulationsproperties können auf Ebene
Application, Show und Simulation spezifiziert
werden. Application ist die "höchste" Stufe,
Simulation die "tiefste". Es wird von hoch nach
tief vererbt. Die tiefere Ebene kan
"überschreiben". Hiermit wird z.B. den
Vergleich eine und derselbe Simulation auf
zwei verschiedenen DB ermöglicht.
SimulationProperties
has
1
1
0..*
0..*
loads
0..*
refers to
Show
DatabaseConne ctionProfile
1
1
1
1
has
composed of
0..*
Simula tionsm odell
0..*
1
Simul ation
runs
1
Simulati onThread
uses
0..*
1
DBConnection
uses
0..*
1
1
0..*
composed of
1. .*
TransactionModel
Isola tionLev el
has
1
0..* -
R%
U%
I
D%
P
applies
1
0..*
refers
0..*
Während der Simulation können die
Isolationsgrade, die Pausezeit, sowie
die R%, U%, I und D% der
verwendeten Thread-Modelle
übersteuert werden.
Re ad
Operation
Update
Ins ert
Del ete
Diagramm 2: Fachklassendiagramm
1.4 Referenzen
[1] "Der Transaktionssimulator", Dr. Arno Schmidhauser, December 2004
[2] Transaktionssimulator Java Code, Dr. Arno Schmidhauser
1.5 Übersicht
Dieses Dokument ist gemäss dem Standard IEEE 830 1998 «Software
Requirements Specification (SRS)» gegliedert1.
Im Kapitel 2 werden die allgemeinen Faktoren beschrieben, welche das Produkt und
die SRS beeinflussen. Kapitel 3 definiert die produktspezifischen funktionalen und
nicht-funktionalen Anforderungen.
1
Übersetzung der englischen Begriffe durch den Autor
Seite 7 von 23
Anforderungen sind mit einem eindeutigen Identifikator versehen und formattiert wie
folgendem im Fettschrift hervorgehobenen Beispiel:
XYZ.1 Dieser Text rechts vom Identifikator XYZ.1, ist die Beschreibung der
Anforderung, welche in der Regel aus einem einzigen Satz besteht.
a)
Dies ist eine Sub-Anforderung, identifiziert durch XYZ.1.a
Nur mit einem Identifikator versehene Sätze sind als Anforderungen zu verstehen.
2 Allgemeine Beschreibung
2.1 Produkt Perspektive
PRO.1 Der Transaktionssimulator soll als Rich-Client implementiert werden, der
über ein Netzwerk auf eine Datenbank zugreift. Im Trivialfall muss die
Datenbank auf demselben Rechner wie der Transaktionssimulator laufen
können.
PRO.2 Die Simulationsmodelle und andere Konfigurationsdaten werden auf einer
Dateiablage des Benutzers gespeichert.
Diagramm 3 zeigt eine Übersicht des Systems Transaktionssimulators.
Transaktionssimulator
Dozent
GUI
Simulator
RDBMS
Konfigurator
Studenten
Filesystem
Diagramm 3: Systemübersicht
2.1.1 System Schnittstellen
Keine. Siehe 2.1.4.
2.1.2 Benutzer-Schnittstellen
Schnittstelle GUI-Dozent
Seite 8 von 23
Der Dozent bedient den Transaktionssimulator, um Simulationsmodelle zu definieren
und Präsentationen vorzubereiten, sowie die Simulationen durchzuführen. Er arbeitet
mit Mouse, Keyboard und PC-Bildschirm. Die Zweckmässigkeit des GUI-Entwurfs für
diese Arbeiten muss anhand eines Prototyps erhoben und vom Kunden beurteilt
werden.
Schnittstelle GUI-Studenten
Der Transaktionssimulator-Rechner kann zum Zweck der Präsentation in einem
Unterrichts-Raum an einen Beamer angeschlossen sein. Die Studenten sitzen im
Vorlesungszimmer und verfolgen die Simulationen auf der Projektionsfläche. Die
Qualität der Darstellung, insbesondere die Anordnung von Inhalten, Kontrast und
Helligkeit, Schriftart und -grösse müssen experimentell anhand eines Prototyps
erhoben und vom Kunden beurteilt werden.
2.1.3 Hardware Schnittstellen
Keine.
2.1.4 Software Schnittstellen
SCH.1 Folgende Software Schnitstellen sind zu unterstützen:
a)
b)
Java Runtime Environment Version ab 1.4 (kapselt u.a. den Zugriff auf
das Filesystem)
JDBC für die Kommunikation mir der Datenbank (JDBC kapselt den
Zugriff auf die Datenbank)
2.1.5 Kommunikations-Schnittstellen
Die Kommunikation erfolgt über die von der JVM (Java Virtual Machine) und JDBC
unterstützte Protokolle, insbesondere TCP/IP.
2.1.6 Speicherbeschränkungen
MEM.1 Der Transaktionssimulator muss mit 1 GB RAM oder mehr im Rechner
laufen können.
MEM.2 Der Transaktionssimulator muss weniger als 30 GB Festplattenspeicher
benötigen.
2.1.7 Betrieb
BET.1 Die Installation soll für den Benutzer einfach sein, z.B. mittels eines einzigen
jar-File zum auspacken, oder on-the-fly Laden und Starten über Internet via
Java Webstart.
Der Transaktionssimulator wird vom User auf einen Rechner installiert und lokal
gestartet und gestoppt.
Der Betrieb der Datenbank ist ausserhalb des Scopes.
2.2 Produktfunktionen
Der Transaktionsimulator bietet folgende Hauptfunktionen:
•
•
•
Verwalten von Simulationsmodellen
Durchführen von Simulationen
Visualisieren und Präsentieren von Simulationsergebnissen
Seite 9 von 23
Es ist keine Funktionalität zum kreieren von Reports vorgesehen.
2.3 Benutzermerkmale
Dozent: Der Dozent ist Informatiker und Experte für Datenbanken.
Studenten: Die Studenten sind angehende Informatiker mit folgenden relevanten
Basiskenntnissen:
•
•
•
•
Sie sind geübt in der Verwendung von GUIs und technischen Anwendungen
Sie können XML anwenden
Sie wurden in Datenbank-Theorie unterrichtet
Sie verstehen Englisch
2.4 Einschränkungen
RES.1 Der Transaktionssimulator muss in Java programmiert werden.
RES.2 Die Schnittstelle zur Datenbank soll so konzipiert werden, dass eine spätere
Einbindung eines auf Java Persistence Framework (JPA) basierten
Persistence Layer ohne grosse Änderungen am Design zwischengeschoben
werden kann.
2.5 Annahmen und Abhängigkeiten
•
•
Das Betriebssystem für die Entwicklung und den Betrieb, ist Windows XP SP2
Die Benutzer verfügen über die erforderlichen Hard- und SoftwareVoraussetzungen, sowie die Permissions für die Installation des
Transaktionssimulators
2.6 Versionierung der Anforderungen
Als Produkt der Diplomarbeit wird eine Version 1.0 ausgeliefert, welche die MUSSAnforderungen erfüllt.
3 Spezifische Anforderungen
3.1 Externe Schnittstellen
3.1.1 Anforderungen an das GUI
Die Anforderungen an das GUI wurden mittels eines LoFi-Prototyps bestehende aus
einem Storyboard mit Visio-Zeichnungen erhoben. Zur Illustration ist in Anhang B
einen Teil dieses Storyboards aufgenommen. Verbindlich sind jedoch nur die
Anforderungen in diesem Kapitel.
GUI.1 Das GUI muss die Resultate von zwei Simulationen nebeneinander («sideby-side») anzeigen können.
GUI.2 Das GUI muss die Resultate einer Simulation in einem Balken-Diagramm
visualisieren.
Seite 10 von 23
GUI.3 Die Axen der Resultat-Grafiken dürfen fix eingestellt sein, d.h. müssen sich
nicht dynamisch an die Messwerte anpassen.
GUI.4 Das GUI muss dem User ermöglichen die Maximalwerte der Axen der
Resultat-Grafiken auf der Show -Ebene ein zu stellen.
GUI.5 Wenn anzuzeigende Ergebniswerte den Maximalwert einer Axe übertreffen,
muss das GUI im Resultat-Grafik nur den Maximalwert zeigen und muss das
GUI im Status-Bar eine entprechende Fehlermeldung zeigen.
GUI.6 Das GUI muss dem User ermöglichen auf Applikations-Ebene ein zu stellen
wie oft die Grafiken pro Sekunde ge-updated werden («Refresh-Rate»).
GUI.7 Das GUI muss Simulations-Resultate darstellen:
a)
Pro Transaktionsmodell der Simulation sowie für die gesamte
Simulation die in SIM.2.a bis SIM.2.d definierten Werte.
b)
Für duie gesamte Simulation die in SIM.2.e und SIM.2.f definierten
Werte.
GUI.8 Das GUI muss dem User ermöglichen eine Simulation zu laden, zu starten,
anzuhalten, und zu stoppen.
GUI.9 Wenn eine Simulation angehalten ist, muss das GUI dem User ermöglichen
folgende Parameter zu ändern:
a)
b)
c)
d)
e)
f)
g)
Transaktionsmodell (zufügen oder löschen)
Relative Menge eines Transaktionsmodells
Isolationsgrad für ein Transaktionsmodell
Prozent gelesener Datensätze (R%)
Prozent geänderte Datensätze von R% (U%)
Anzahl geänderte Datensätze pro Transaktion (I)
Prozent gelöschter Datensätze (D%)
GUI.10 Das GUI muss dem User ermöglichen eine angehaltene Simulation
weiterlaufen zu lassen. Die Simulation muss dabei die eventuell
angepassten Parameter verwenden.
GUI.11 Das GUI ermöglicht dem User das Zeitfenster für die Berechnung der
gleitenden Durchschnittswerte auf Applikations-Ebene ein zu stellen.
3.1.2 Anforderungen an die Datenbank-Schnittstelle
DAT.1 Die Anwendung muss auf Simulations-Ebene auf unterschiedliche
Datenbank-Produkte zugreifen können (innerhalb desselben
Programmlaufes).
DAT.2 Der Zugriff auf die Datenbank muss über JDBC erfolgen.
DAT.3 Die Anwendung muss die benötigten Datenbank-Treiber laden. Die Treiber
selber sind nicht im Lieferumfang des Transaktionssimulators.
3.2 Funktionale Anforderungen
3.2.1 Anforderungen an den Simulator
SIM.1 Der Simulator funktioniert gemäss dem im [1] und [2] sowie Anhang A
dargelegten Prinzip.
SIM.2 Der Simulator erfasst pro Transaktionsmodell für das eingestellte Zeitfenster
folgende Werte:
Seite 11 von 23
a)
b)
c)
d)
e)
f)
Anzahl Transaktionen
Anzahl Deadlocks
Anzahl Missed Updates
Anzahl Phantoms
Transaktionszeit
Deadlock-Zeit
SIM.3 SQL-Ausdrücke insbesondere für Locking, Transaktionen sowie DatanbankOptionen, müssen als Konfigurationsdaten produktspezifisch einstellbar sein.
SIM.4 Der Simulator muss die Isolationsgrade 0 bis 3 unterstützen.
SIM.5 Der Simulator muss folgende Parameter verwenden:
a)
b)
c)
d)
e)
Simulationszeit in Sekunden. 0 = kontinuierlicher Lauf
Zeitfenster für die Berechnung gleitender Durchschnitte
Anzahl gleichzeitige Threads
DatabaseConnectionProfile welche die Datenbank definiert worauf die
Simulation ausgeführt werden soll
(Optional) Database-Spezifische Optionen können ausgewählt werden
3.2.2 Anforderungen an den Konfigurator
CON.1 Der Konfigurator bietet dem User die Möglichkeit folgende Entitäten zu
verwalten (siehe auch Fachklassendiagramm):
a)
b)
c)
d)
e)
Show
Simulation
Transaktions-Modell
Simulationsparameter
DatabaseConnectionProfile
CON.2 Ein Simulationsmodell besteht aus (k)einem oder mehreren
Transaktionsmodellen und deren relativen Mengen.
CON.3 Ein Transaktionsmodell hat besteht aus folgenden Parametern:
a)
b)
c)
d)
e)
f)
g)
Transaktionsmuster (z.B. RR oder RU)
Isolationsgrad (0-3)
Anzahl gelesene Datensätze in Prozent (R%)
Anzahl geänderte Datensätze in Prozent von R% (U%)
Absolute Anzahl geänderte Datensätze (I)
Anzahl der gelöschten datensätze in Prozent (D%)
(Optional) Flag ob Transaktion mit Commit abgeschlossen wird
CON.4 Die Konfiguration der Modelle muss in einer lokal abgelegten XML-Datei
erfolgen.
CON.5 Optional gietet das GUI dem Benutzer die Möglichkeit die Konfiguration der
Modelle im GUI vor zu nehmen.
CON.6 Für den Abnahmetests müssen folgende zwei Konfigurationen (Szenarien)
konfiguriert werden können:
a)
Szenario "OLTP-Benutzer"
Seite 12 von 23
Anteil
Transaktionsmuster
gelesen
2
R
10%
1
RU
10%
10
1
RD
1%
10
1
RI
1%
10
b)
Pause (ms)
Szenario "OLAP-Benutzer"
Anteil
Transaktionsmuster
gelesen
Pause (ms)
3
RR
10%
100
2
RRR
70%
500
1
RRRR
100%
1000
3.3 Leistungsanforderungen
3.4 Design Constraints
DES.1 Für folgende Modulen müssen abstrakte Schnittstellen verwendet werden,
damit verschiedene Implementationen verwendet werden können (compiletime):
a)
b)
c)
d)
Simulator
Visualisierung der Simulationsergebnisse
Datenbank-Produkt
Optional: Datenzugriff (JDBC und JPA)
DES.2 Die in GUI.6 und SIM.5 definierten Parameter müssen auf der Ebene
Application, Show und Simulationsmodell definiert werden können, wobei die
tiefere Ebene Vorrang über die höhere Ebene hat.
3.5 Qualitätsanforderungen
3.5.1 Zuverlässigkeit (Reliability)
Keine.
3.5.2 Verfügbarkeit (Availability)
Nicht abgefangene Exceptions sollen mit einem globalen Catch-All abgefangen und
in einem Log erfasst werden..
3.5.3 Sicherheit (Security)
Keine.
3.5.4 Wartbarkeit (Maintainability)
WAR.1 Der Code soll angemessen kommentiert sein.
Seite 13 von 23
3.5.5 Portabilität (Portability)
Keine. Die Portabilität zwischen verschiedene Betriebssystem ist durch die
Implementierung in Java gegeben.
3.6 Sonstige Anforderungen
3.6.1 Supportability
Keine.
3.6.2 Online user documentation and help system requirements
Keine.
3.6.3 Eingekaufte Komponenten
EK.1
Die Beschaffungskosten eingekaufter Komponenten dürfen SFr. 200.- nicht
übersteigen.
3.6.4 Lizenzierung
LIZ.1
Die Berner Fachhochschule erhält die Verwertungsrechte auf das Produkt für
nicht-kommerzielle Zwecke im Rahmen ihrer Ausbildungsaufgaben.
LIZ.2
Bei der Verwendung von Softwaremodulen von Dritter (u.a. auch Open
Source) müssen die in den Lizenzvereinbarungen festgehaltenen
Restriktionen und Auflagen eingehalten werden.
3.6.5 Rechtliches, Urheberrechte and andere Vermerke
LEG.1 Urheber der Software und Begleitdokumente ist Paul Klarenberg.
LEG.2 Bei der Verwendung von Modulen Dritter (u.a. Open Source) müssen die in
den Lizenzvereinbarungen verlangte Vermerke umgesetzt werden.
3.6.6 Usability
Siehe Anhang B.
3.6.7 Anzuwendenden Standards
Wenn SQL-Ausdrücke im Code verwendet werden, müssen diese SQL-99 konform
sein.
Seite 14 von 23
Anhang A. Funktionsprinzip Simulator
Zusammenfassung von [1] und [2].
Die Testtabelle TrxTable, auf der alle Transaktionen operieren, hat folgende
Attribute:
name
typ
Beschreibung
pkey
numeric(10,0)
autoincrement
Primärschlüssel. Wir in der Applikation für den Update
benötigt.
searchKey
double
Nach diesem Attribut wird beim Lesen gesucht. Die Werte
sind zufällig zwischen 0 und 100 verteilt. Auf diesem Feld
besteht ein Index.
data
int
Dieses Feld wird gelesen und in nach¬folgenden UpdateBefehlen jeweils um 1 inkrementiert.
tranCount
int
Dieses Attribut wird unmittelbar bei jedem Update-Befehl
um 1 inkrementiert.
Bemerkungen
Standardmässig wird die Testtabelle mit 100 Datensätze initialisiert. Wesentlich mehr
oder weniger Datensätze erhöhen oder erniedrigen die Wahrscheinlichkeit für
Deadlocks, Phantoms, Lost Updates, Optimistic Rollbacks in nicht-linearer Weise:
Um didaktisch anschauliche Resultate zu demonstrieren, müssen entsprechende
Tests gefahren werden.Jeder Thread-Instanz akkumuliert die Ergebnisse jeder
einzelne Transaktion in seine ThreadStatistics
Die Thread-Klasse akkumuliert die die SystemStatistics
Erste R-Operation (in den Transaktionsmodellen R, RR und RU)
Sollen beispielsweise 10% der Datensätze gelesen werden, sucht die Simulation
einen zufälligen Startwert für searchKey zwischen 0 und 90. Ausgehend von diesem
Startwert werden die nächsten 10% gelesen, d.h.
SEL_PRCNT = 10
lowSelBound = Random * (100 - SEL_PRCNT)
maxSelBound = lowSelBound + SEL_PRCT
(lowSelBound, maxSelBound) werden in folgendem SQL-Statement für die
Fragezeichen substituiert
SELECT primKey, data, tranCount FROM TrxTable
WHERE searchKey >= ? AND searchKey < ?
Seite 15 von 23
das Statement ausgeführt, und die Daten in einen RecordSet rs eingelesen.
U-Operation
Die Simulation nimmt nur eine einzige Art Änderung auf dem Wert von data vor: Der
Wert wird in der Applikation um 1 erhöht und anschliessend zurückgeschrieben. Der
Wert von tranCount wird im Update-Befehl um 1 erhöht (wenn der Datensatz also
bereits mit einer exklusiven Sperre belegt ist).
Der in der R-Operation eingelesene RecordSet rs wird jetzt durchlaufen. Wenn für
einen Datensatz gilt:
Random * 100 <= UPD_PRCNT
denn werden die gelesenen Werte für (data, primKey) in folgendem SQL Statement
UPDATE TrxTable
SET data = ? + 1, tranCount = tranCount + 1
WHERE primKey = ?
substituiert und schliesslich das Statement ausgeführt.
Das UPDATE Statement gibt die Anzahl mutierten Datensätze zurück und es wird im
Normalfall den Wert 1 zurück erwartet. Wenn aber der Wert 0 zurück kommt heisst
das, dass der Datensatz nicht mehr vorhanden ist, weil eine D-Operation diesen
vorher gelöscht hat. Diesen Fall wird als «Missed Update» d.h. ein Lost Update
gezählt un in totalMissedUpdates totalisiert.
Die zweite R-Operation (im Transaktionsmodell RR)
Die Datensätze im RecordSet rs werden mit rs.next() gezählt und die Summe in
count1 gespeichert. Danach wird denselben SQL-Code wie in der ersten ROperation ausgeführt, wobei (lowSelBound, maxSelBound) wieder substituiert
werden
SELECT primKey, data, tranCount FROM TrxTable
WHERE searchKey >= ? AND searchKey < ?
und die Datensätze in einen neuen RecordSet rs eingelesen und anschliessend mit
rs.next() gezählt, und die Summe in count2 gespeichert.
I-Operation
INSERT TrxTable
WHERE searchKey >= ? AND searchKey < ?
Seite 16 von 23
D-Operation
DELETE TrxTable
WHERE serachKey >= ? AND searchKey < ?
Lost Updates
Lost Updates können auftreten, wenn mehrere Transaktionen denselben Wert lesen,
bearbeiten, und später das Ergebnis zurückschreiben bzw. einen Datensatz löschen,
also beim Transaktionsmuster RU und einer Mischenung von RU und D.
Die Differenz zwischen data und tranCount entspricht der Anzahl Lost-Updates.
SELECT SUM(tranCount - data)
FROM TrxTable
hinzugezählt werden müssen aber noch die totalMissedUpdates.
Phantoms
Phantome treten nur bei wiederholtem lesen, also bei Transaktionsmuster RR auf in
Kombination mit einer I-Operation. Die Zahl ergibt sich aus abs(count2 - count1).
Deadlocks
Die Deadlock werden gezählt nach der entsprechende Anzahl SQLExceptions
welche geworfen werden mit SQLState = 40001.
Seite 17 von 23
Anhang B. LoFi Prototyp GUI
Seite 18 von 23
Seite 19 von 23
Seite 20 von 23
Seite 21 von 23
Seite 22 von 23
Seite 23 von 23