Zu den wichtigsten Aufgaben von openUTM gehört es, die Konsistenz und Integrität der Anwendungsdaten sicherzustellen - auch dann, wenn Probleme auftreten, wie z.B. Netzstörungen oder Systemausfälle. Deshalb unterliegen alle Abläufe unter openUTM dem Transaktionskonzept.
Eine Transaktion ist eine Zusammenfassung von Arbeitsschritten, die ganz bestimmte Eigenschaften aufweist. Diese Eigenschaften werden üblicherweise entsprechend ihren Anfangsbuchstaben als ACID-Eigenschaften bezeichnet:
Atomicity
Die zu einer Transaktion zusammengefassten Arbeitsschritte bilden eine atomare Einheit: Entweder werden alle Arbeitsschritte einer Transaktion ausgeführt oder gar keiner (Alles-oder-Nichts-Regel). Falls eine Transaktion aus irgendeinem Grund nicht vollständig durchgeführt werden kann, wird die Transaktion zurückgesetzt (rollback), d.h. alle Daten werden auf den Zustand vor Beginn der Transaktion zurückgesetzt.Consistency
Die Arbeitsschritte werden korrekt durchgeführt. Falls die Ressourcen (Datenbanken, Drucker, Message Queues etc.) sich vor Transaktionsbeginn in einem konsistenten Zustand befanden, befinden diese sich auch nach Ende der Transaktion in einem konsistenten Zustand.Isolation
Falls mehrere Transaktionen zeitlich überlappend stattfinden, werden konkurrierende Änderungen so ausgeführt, als wären die Transaktionen serialisiert, d.h. ohne Überlappung ausgeführt worden. Zwischenstände werden nicht für andere Transaktionen sichtbar. Die Transaktionen sind gegeneinander isoliert.Durability
Ist eine Transaktion einmal erfolgreich abgeschlossen, so sind die vorgenommenen Änderungen dauerhaft, d.h. sie überstehen auch Systemausfälle. Beim Transaktionsende werden hierzu alle Änderungen gesichert. Das Transaktionsende stellt daher immer auch einen Sicherungspunkt dar.
So erfüllt z.B. eine Geldüberweisung, in der die Arbeitsschritte „Betrag abbuchen“ und „Betrag gutschreiben“ zusammengefasst sind, die Atomicity-Bedingung, wenn nach jeder Abbuchung immer auch eine Gutschrift erfolgt. Die Überweisung erfüllt die Consistency-Bedingung, wenn sowohl Abbuchung als auch Gutschrift in der vorgeschriebenen Form und an der richtigen Stelle eingetragen werden. Die Isolation-Bedingung ist erfüllt, wenn keine Gefahr besteht, dass während der Bearbeitung parallele Buchungen die beteiligten Kontostände lesen und verändern. Die Durability-Bedingung schließlich ist erfüllt, wenn die Aktualisierung bei Systemstörungen, wie z.B. einem Stromausfall, nicht verlorengeht.
openUTM bezieht alle Ressourcen komplett in die Transaktionssteuerung ein und ist so in der Lage, umfassende Restart-Funktionen (automatischer Wiederanlauf) zu bieten.
Beim automatischen Wiederanlauf synchronisiert openUTM nicht nur die Daten in den Datenbanken mit den Daten in der Anwendung neu, sondern auch unterbrochene Services, lokale Betriebsmittel (z.B. Speicherbereiche), Queues, Kommunikationsverbindungen und alle Frontends wie Terminals, PCs, Workstations und Drucker.
Diese Restart-Funktionalität ermöglicht es beispielsweise, dass selbst nach Systemausfällen (PCs, Netz, Server) alle Client-PCs mit dem jeweils letzten konsistenten PC-Bildschirm weiterarbeiten können.
| Weitere Informationen zum Thema „Wiederanlauf“ finden Sie in diesem Handbuch im Abschnitt „Wiederanlauf-Funktionen von openUTM". |
