OLTP bedeutet „Online Transaction Processing“, also das Bearbeiten von Daten innerhalb von Transaktionen im Dialog.
Damit gehören alle Dialog-Anwendungen, auf die mehrere Benutzer zugreifen können und die Datenbestände ändern, zu den OLTP Anwendungen.
OLTP setzt eine entsprechende Middleware, den Transaktions-Monitor, voraus.
Hier sind zu nennen IBM IMS DC (z/OS), IBM CICS (primär z/OS), FSC UTM (BS2000), EJB und viele andere mehr.
Eine Middleware Komponente stellt für die Ablage der Daten im Rahmen eines Transaktions Kontexts sicher, bei IBM IMS kann dieses die integrierte hierarchische Datenbank (oder DB2) sein, bei CICS oder UTM ist es meist die Datenbank (DB2 bzw. SESAM) des Herstellers und bei EJB kann (konnte?) es alles, inkl. dem Filesystem, sein.
Exkurs Datenbanken:
Datenbanken, insbesondere mit der „Abfragesprache“ SQL, werden häufig als Tool gesehen, mit dem Datenbestände abgefragt werden können. Die Hauptaufgabe einer Datenbank ist jedoch das Speichern von Daten nach dem ACID Prinzip (Atomicity, Consistency, Isolation, Durability).
Ermöglicht ein Transaktions-Monitor als Persistenz-Medium auch Nicht-ACID Medien, also zum Beispiel Flatfiles, egal ob einfach strukturiert oder als XML, im Filesystem, muss der Transaktions-Monitor ein ACID Verhalten selber sicherstellen, was zu einem massiven Aufblähen der Systemanforderungen und vor allem des Codierungsaufwands führt.
Eine weitere Komponente, die ein Transaktions-Monitor benötigt, ist ein „Terminal“, also die Schnittstelle zum Benutzer, der die OLTP Anwendung nutzen. Neben den früher verwendeten IBM 3270 Terminal (ISPF) oder FSC 9750 (TransData) sind heute primär Microsoft Windows, die verschiedenen Java APIs (AWT, Swing, SWT) sowie HTML.
Heute werden die OLTP Anwendungen meist auf mehreren Computer ausgeführt. Es sind neben dem Client der Präsentation-Server, Anwendungs-Server (EJB Container) sowie der Datenbank-Server. Häufig findet man noch mehrere Instanzen der Anwendungs-Server, die entweder identische Funktionalität besitzen oder auf bestimmte Bereiche spezialisiert sind. Um diese Rechner in einem Transaktions-Kontext miteinander zu verbinden, wird eine Message-Orientierte Middleware benötigt. Als Standard in der Java-Welt gilt JMS, konkrete kommerzielle Produkte sind zum Beispiel IBM MQ-Series, das die Grundlage für IBM WebSphere bildet und daher als IBM WebSphere MQ vermarktet wird oder Bea WebLogic, also eigentliche jeder EJB-Container.
Von aussen betrachtet ist eine WebSphere oder eine WebLogic Installation vergleichbare mit einer IMS-DB/DC Installationen, es ist eine Lösung, die von der Bildschirm-Maske über die Transaktions-Logik bis zur Persitenz alles abdeckt.
Ein weiterer am Markt weit verbreiteter Transaktions-Monitor, auch wenn man ihn als solchen kaum wahrnimmt, ist SAP R/3. Hier stehen die Business-Prozesse im Vordergrund, um sie sicher abbilden zu können, ist jedoch eine starke Middleware notwendig.
Das „wer schreibt wann“ auf die Datenbank ist eine wichtige Unterscheidung zwischen den Möglichkeiten, ein OLTP System zu implementieren. Hier gibt es grundsätzlich zwei Möglichkeiten:
Der Task, der die Benutzereingaben entgegen nimmt, schreibt auch auf die Datenbank.
Der Task, der die Benutzereingaben entgegen nimmt, übergibt sie (nach einer Vorprüfung) an einen asynchronen Bucher-Task.
Der asynchrone Bucher erhöht den Aufwand bei der Implementierung, so dass im klassischen Mainframe-Umfeld bei kleineren Installationen gerne hierauf verzichtet wird. EJB kennt auch keinen Bucher-Task, da nach der Definition Business-Objekte als Java-Objekte zwischen den einzelnen Komponenten ausgetauscht werden und bei Bedarf persistent abgelegt werden.
Der Asynchrone Bucher sorgt aber für eine wesentlich bessere Skalierbarkeit der Anwendung.
Da nur dieser eine Task, der sequentiell die fertiggestellten Benutzer-Interaktionen bearbeitet, auf die Datenbank schreiben darf, wird die Datenbank nicht mit der Verwaltung von Satzsperren überlastet.
Die Datenbank ist die limitierende technische Komponente eines jeden OLTP Systems. Anwendungs- und Präsentation-Server können in beliebiger Anzahl parallel laufen, ein Datensatz bleibt jedoch ein Datensatz und muss deshalb in einer bestimmten Tabelle in einer bestimmten Datenbank vorhanden sein.
Durch die Entlastung der Datenbank erhöht man somit die mögliche Anzahl der Transaktionen pro Sekunde beziehungsweise die Anzahl der Online-Benutzer für eine (preiswerte) Hardware-Plattform.
Dafür muss jedoch der Anwendungsentwickler für die Satzsperren auf logischer Ebene sorgen. Die Sperren können in einer Tabelle verwalten werden, es kann jedoch auch der „Update-Timestamp“ als Kennzeichen, ob ein Datensatz geändert wurde, verwendet werden.