DE102013204521B4

DE102013204521B4 - Transaktionsverwaltung für Datenbanksysteme

Info

Publication number: DE102013204521B4
Application number: DE102013204521.2A
Authority: DE
Inventors: Harold Wade Cain III; Donna N. Dillenberger; Michel H.T. Hack; Hong Min; Gong Su; James Zu-chia Teng
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2012-03-30
Filing date: 2013-03-15
Publication date: 2024-04-25
Anticipated expiration: 2033-03-16
Also published as: GB201303662D0; GB2501800B; US20180113895A1; US20130262424A1; CN103365652B; CN103365652A; DE102013204521A1; GB2501800A; US9870384B2; US10885015B2

Abstract

Hierin werden Systeme, Verfahren und Produkte zur Transaktionsverwaltung für Datenbanksysteme bereitgestellt. Ein Aspekt sieht das Annotieren eines auf einer Datenverarbeitungseinheit vorhandenen Datenobjektes mittels der Datenverarbeitungseinheit unter Verwendung wenigstens eines Transaktions-Tag vor, wobei das wenigstens eine Transaktions-Tag so konfiguriert ist, dass es einen Status eines dazugehörigen Datenobjektes anzeigt; das Verarbeiten wenigstens einer Datenbanktransaktion unter Verwendung eines transaktionsorientierten Speicherprozesses, wobei ein Zugriff auf das wenigstens eine Datenobjekt auf der Grundlage des Status des wenigstens einen Datenobjektes festgelegt wird; und das Aktualisieren des Status des wenigstens einen Datenobjektes als Reaktion auf einen versuchten Zugriff auf das wenigstens eine Datenobjekt durch die wenigstens eine Datenbanktransaktion. Hierein werden darüber hinaus weitere Ausführungsformen und Aspekte beschrieben.

Description

GEBIET DER ERFINDUNG
Der hierein beschriebene Gegenstand betrifft im Allgemeinen die Verarbeitung und Verwaltung von Datentransaktionen in einem Datenbankverwaltungssystem (DBMS, database management system), insbesondere unter Verwendung von transaktionsorientierten Speichern.
HINTERGRUND
Transactional Memory (TM, transaktionsorientierter Speicher) ist ein Mechanismus zur Concurreny Control (Überprüfung auf gleichzeitige Lese- und Schreiboperationen), die eine weniger fehleranfällige Parallelprogrammierung ermöglicht und vereinfacht. Im Allgemeinen ist mit TM ein flexibles Verfahren möglich, mit dem Programme unterschiedliche Speicherorte im Sinne einer atomaren Operation einzeln lesen und modifizieren können, was der atomaren Datenbanktransaktion ähnelt, bei der eine Vielzahl von Einträgen auf einer Platte (disk) modifiziert werden. So kann TM beispielsweise einen optimistischen Ansatz anwenden, um möglicherweise die Ausführungsgleichzeitigkeit für Multi-Thread-Programme zu erhöhen, die auf dieselben oder überlappende Sätze von mehreren Speicherorten zugreifen. Um eine optimistische Ausführung (optimistic execution) zu erzielen, kann eine TM-Ausführungsumgebung bestimmte Funktionen, einschließlich Konflikterfassung (conflict detection), Versionsverwaltung (version management) und Konfliktlösung (conflict resolution), nutzen. TM kann in Hardware (HTM), Software (STM) oder als hybride Kombination aus Hardware und Software implementiert werden.
Die Erfindung stellt sich die Aufgabe, neben Transaktionen mittels Hardware-transactional-memory-Speichern auch Software-basierte Transaktionen durchzuführen.
Diese Aufgabe wird erfindungsgemäß gelöst durch ein System zum Ausführen von Datenbanktransaktionen nach Anspruch 1, ein Verfahren zum Ausführen von Datenbanktransaktionen nach Anspruch 11 und ein Computerprogrammprodukt zum Ausführen des Verfahrens zum Ausführen von Datenbanktransaktionen nach Anspruch 13. Bevorzugte Ausführungsformen der Erfindung sind Gegenstand der jeweiligen Unteransprüche.
KURZDARSTELLUNG
Ein erfindungsgemäßes System zum Ausführen von Datenbanktransaktionen umfasst wenigstens einen Prozessor und eine Speichereinheit, die funktionell mit dem wenigstens einen Prozessor verbunden ist. Der wenigstens eine Prozessor ist so konfiguriert, dass er das nachfolgend dargestellte Verfahren ausführen kann.
Ein erfindungsgemäßes Verfahren zum Ausführen von Datenbanktransaktionen weist im wesentlichen die Schritte auf: Annotieren wenigstens eines Datenobjektes unter Verwendung wenigstens eines Transaktions-Tags; Verarbeiten wenigstens einer Datenbanktransaktion und Aktualisieren des Status des wenigstens einen Datenobjektes als Reaktion auf einen versuchten Zugriff. Einzelheiten dieser Verfahrensschritte, die auch auf einem Computerprogrammprodukt gespeichert werden können, werden im folgenden erläutert.
KURZBESCHREIBUNG DER MEHREREN ANSICHTEN DER ZEICHNUNGEN
Die Erfindung wird im folgenden anhand von in der beigefügten Zeichnung dargestellten bevorzugten Ausführungsformen erläutert.

1 stellt einen beispielhaften Transaktionsprozess in einem Datenbanksystem dar.
2 stellt beispielhafte Objektdatenstrukturen dar, die gemäß Ausführungsformen konfiguriert sind.
3 stellt ein Beispiel für eine Transaktionsverarbeitung gemäß einer Ausführungsform dar.
Die 4A bis 4C stellen beispielhafte Anwendungsprogrammierschnittstellen (application programming interfaces, APIs) und dazugehörige Implementierungen gemäß Ausführungsformen dar.
Die 5A und 5B stellen beispielhafte Anwendungsprogrammierschnittstellen (APIs) und Implementierungstransformationen dar, die gemäß Ausführungsformen konfiguriert sind.
6 veranschaulicht eine beispielhafte Datenverarbeitungseinheit.

AUSFÜHRLICHE BESCHREIBUNG
Transactional Memory (TM) bietet viele Vorteile, unter anderem eine vereinfachte Parallelprogrammierung sowie weniger Schwierigkeiten, die mit dem Schreiben paralleler Programme einhergehen. Dennoch weist TM eigene Schwachstellen auf, wie beispielsweise Leistungseinbußen, weil Transaktionsprotokolle geführt sowie Konflikte erfasst und gelöst werden müssen. Die Leistungseinbußen können durch ein vollständiges Implementieren von TM in Hardware minimiert werden (HTM). Dies beschränkt jedoch notwendigerweise aufgrund der begrenzten Hardwareressourcen und zugrundeliegender Cache-Kohärenz-Protokolle, die vom HTM zur Unterstützung von Kohärenz für mehrere Daten verwendet werden können, die Datengröße, auf die eine Transaktion zugreifen kann. Demzufolge müssen Systeme für Transaktionen, die auf eine große Datenmenge zugreifen, entweder auf herkömmliche Locking-Verfahren oder auf Software beruhenden TM (SMT) zurückgreifen, wodurch aufgrund einer sehr hohen Leistungseinbuße möglicherweise der Vorteil der Gleichzeitigkeit aufgehoben wird.
Ein TM-aktiviertes Programm deklariert einen Transaktionsumfang als kritischen Ausführungsabschnitt (critical execution section), der einen oder mehrere Speicherorte berührt. HTM löst die Konflikte im Hinblick auf Granularität einer Speicher-Manipulationseinheit, wie beispielsweise einer Cache-Zeile. Im Hinblick auf die Deklarierung einer Arbeitseinheit (unit of work) und ihre Wiederherstellung existieren ähnliche Strukturen (constructs) in Datenbankverwaltungssystemen (database management systems, DBMS). So kann eine Anwendung beispielsweise vor dem Lesen oder Modifizieren eines Satzes von Datenbankobjekten einen „Start der Wiederherstellungseinheit“ („start of the unit of recovery (UR)“) deklarieren. An einer Stelle kann die Anwendung dann ein „Commit“ oder „Roll back“ ausgeben, um die Änderungen in der Datenbank zu bestätigen („Commit“) oder sämtliche Änderungen seit dem Befehl „Start der UR“ rückgängig zu machen („Rollback“).
Im Allgemeinen kann ein Datenbankeintrag jede beliebige Größe aufweisen, die von dem DBMS unterstützt wird. Ein DBMS kann einen Software-Lock-Manager verwenden, um Parallelzugriffe auf dieselben Datenentitäten (data entities) zu serialisieren, wobei nur der Thread, der die Sperre (lock) erhält, zu seinem Zugriff gelangen kann. Je nach Anwendungssemantik können weitere Threads, die einen Zugriff auf dieselben Entitäten beabsichtigen, blockiert werden, was ebenfalls von der Semantik abhängt. Ein Lock-Manager kann Objekte anhand ihrer Namen oder Kennungen unterscheiden. Auf diese Weise kann Serialisierung der Granularität auf Tabellenebene, Dateiebene (eine Tabelle kann partitioniert werden und sich über mehrere Dateien erstrecken), Eintragsebene oder Seitenebene (es können ein oder mehrere Einträge auf einer Seite gespeichert werden oder sich über mehrere Seiten erstrecken, wobei es sich gleichzeitig um die Einheit zur E/A handelt) erzielt werden. Das Sperren von Objekten (object locking) kann jedoch sehr kostenintensiv sein. Ein Übergang zwischen den Hierarchien unterschiedlicher Sperrebenen kann ebenfalls möglich sein. Schließlich handelt es sich dabei auch um eine Kompromisslösung zwischen den Faktoren Gleichzeitigkeit (concurrency), Leistung und Systemressourcen. Das Serialisieren von Zugriff auf einzelne Objekte mittels Sperren (locking) in einer Umgebung, in der sich eine Transaktion auf mehrere Objekte erstreckt, kann des Weiteren zu einer Verklemmung („deadlock“) führen, die von einem Lock-Manager gelöst werden muss.
In 1 ist ein beispielhafter Datenbankverwaltungsprozess dargestellt. Ein System besteht aus einer Datenbank 101, die Tabellen 102, Seiten 103 und Zeilen 104 enthält, einem Anwendungs-Thread 105 und einem Lock-Manager 106. Eine Transaktion wird gestartet 107, und ein oder mehrere Objekte (z.B. table.page.row innerhalb der Datenbank 101) werden positioniert (located) 108. Die Erlaubnis des Lock-Managers für den Zugriff auf das eine oder die mehreren Objekte wird angefordert 109. Wird die Erlaubnis erteilt 110, kann der Zugriff auf das eine oder die mehreren Objekte erfolgen, anderenfalls wartet der Prozess 111. Der Prozess geht zu einem erneuten Anfordern der Erlaubnis zum Zugriff auf ein Objekt über 109 zurück. Der Prozess kann so konfiguriert sein, dass er ein „Commit“ (Annehmen der Transaktion) oder ein „Abort“ (Verwerfen der Transaktion) erteilt und aktive Locks (Sperren) aufhebt.
Hardware Transaction Management (HTM) ist ein durch Hardware gestützter lock-freier Mechanismus für die Konfliktlösung beim Datenzugriff. Es gewährleistet eine gute Leistung, gleichzeitig weist es einige eigene Grenzen auf, wie beispielsweise beschränkte Datengrößen und das Unvermögen, einen gleichzeitigen Zugriff (concurrent access) auf unterschiedlichen Objekthierarchieebenen verwalten zu können. Zusätzlich zu Einträgen, Seiten, Dateien und Tabellen erfordern viele Anwendungen atomare Operationen an noch größeren Datenstrukturen, insbesondere Datentypen wie Text, XML-Dokumente, binäre Objekte und Bilder.
Dementsprechend stellen Ausführungsformen ein Transaktionsverarbeitungssystem bereit, das auf HTM beruhend arbeitet und so konfiguriert ist, dass es ohne einen Lock-Manager funktioniert. So stellen Ausführungsformen beispielsweise einen hybriden Ansatz bereit, bei dem ein optimistischer Mechanismus und ein Blockierungsmechanismus (blocking mechanism) zur Ausführung von Datenbanktransaktionen an verschiedenen Datenobjekten kombiniert werden. Der hybride Ansatz zum Ausführen von Datenbanktransaktionen gemäß Ausführungsformen kann so konfiguriert sein, dass er den Vorteil der vereinfachten Programmierschnittstelle des Transactional Memory (TM) nutzt und unter Verwendung von HTM einen Teil der Konflikterfassung und - lösung mit dem Ziel übernimmt, eine bessere Leistung als ein Lock-Manager zu erzielen. Datenbankobjekttransaktionen, die den hybriden Ansatz in der hierin offenbarten Form verwenden, werden realisiert, indem unter Ausnutzung des Vorteils von TM die Datenbank-Objektstruktur erweitert und gleichzeitig Datenkonsistenz innerhalb eines Objektes beibehalten wird, ohne dass auf alle von dem Objekt besetzten Speicherorte zugegriffen werden muss. In einem nicht einschränkenden Beispiel können APIs zum Bearbeiten der Datenbankobjekte bereitgestellt werden, einschließlich, jedoch nicht beschränkt auf, APIs zum Daten-Tagging oder zur Datenannotation, um das Problem der begrenzten Transaktionsgröße zu verringern, wobei ein Language Interpreter oder Compiler zum Bearbeiten von Übersetzungen von Annotationen verwendet werden kann. Eine gemäß Ausführungsformen konfigurierte Transaktionsverarbeitung kann unter anderem eine bessere Leistung als bisher verfügbare Transaktionsverarbeitungssysteme bei weniger Verklemmungen („deadlocks“) oder Wartezeit bis zur Freigabe von Sperren (lockwait timeout) erzielen.
2 stellt beispielhafte Objekte in einem hybriden System dar, das gemäß Ausführungsformen konfiguriert ist. Das hybride System besteht aus einer Datenbank 201, die Tabellen 202, Seiten 203 und Zeilen 204 enthält. Gemäß Ausführungsformen können Systemobjekten Tags hinzugefügt werden, die für eine zu den Objekten gehörende Systemanwendung (z.B. einen Anwendungs-Thread) transparent sind. Wie dies in 2 dargestellt ist, kann ein transaktionsorientiertes Tabellen-Tag 205 einer Tabelle 202 zugeordnet sein, ein transaktionsorientiertes Seiten-Tag 206 kann einer Seite 203 zugeordnet sein und ein transaktionsorientiertes Zeilen-Tag 207 kann einer Zeile 204 zugeordnet sein. Jedes Tag kann einem Zustand (state) zugeordnet und so konfiguriert sein, dass es die Verfügbarkeit (accessibility) eines dazugehörigen Objektes oder dazugehöriger Objekte und von einer oder mehreren Datenstrukturen 208, 209 anzeigt, die so konfiguriert sind, dass sie die Operation des TM-Systems unter Verwendung der transaktionsorientierten Tags 205 bis 207 unterstützen. Ausführungsformen stellen sicher, dass die Tag-Aktualisierungen unter Verwendung von optimistischem lock-freiem HTM bearbeitet werden können.
In 3 ist ein beispielhafter hybrider Prozess dargestellt, der gemäß einer Ausführungsform konfiguriert ist. Der Prozess interagiert mit einer Datenbank 301 und einem Anwendungs-Thread 302. Eine Transaktion wird initiiert 303, und gemäß Ausführungsformen wird ein Zugriff auf Objekte gewährt 304, beispielsweise durch optimistisches lock-freies (lock-free) Aktualisieren von Objekt-Tags innerhalb einer Tagged_HTM_Tx-Funktion, die folgendermaßen konfiguriert sein kann:

      Tagged_HTM_Tx_begin;
             Aktualisieren (aller Objekte im Transaktionsumfang);
      ODER
             Verwerfen und erneut versuchen/aussetzen ("abort and re-try/suspend")
      Tagged_HTM_Tx_end;

Darüber hinaus kann im Anschluss an die Tagged_HTM_Tx-Funktion ein Aktualisieren eines Tag zum Rückgängigmachen eines Objektes (undo object tag) unter Verwendung von HTM optimistisch und lock-frei initiiert werden. Anschließend können Objekte für die Transaktion angenommen werden (committed) 305. Als ein Ergebnis des in 3 dargestellten Prozesses kann ein dichterer (tighter) Transaktionscode erzielt werden, unter anderem Implementieren von Schnittstellen zur Blockaktualisierung zwischen Ebenen der Data-Engine (data engine layers).

Wie dies vorstehend hierin beschrieben wurde, kann der hybride Prozess gemäß Ausführungsformen so konfiguriert sein, dass er zum Ausführen von Datenbanktransaktionen an verschiedenen Datenobjekten einen optimistischen Mechanismus mit einem Blockierungsmechanismus kombiniert. Ausführungsformen gewährleisten, dass ein Zugriff auf ein Datenobjekt die folgenden zwei Funktionen beinhaltet: (1) Reservieren des Rechts auf einen Zugriffsversuch und die Zugriffsoperation, beispielsweise unter Verwendung von HTM zum Behandeln des Zugriffsversuchs und der damit zusammenhängenden Konflikterfassung und -lösung; und (2) anschließend an das Reservieren des Zugriffsversuches Einstellen der Datenzugriffsoperation als lock-frei, so dass, falls das Recht auf Zugriffsversuch nicht reserviert wird, die Datenzugriffsoperation blockiert werden kann.

Die Transaktionsverarbeitung kann gemäß Ausführungsformen so konfiguriert sein, dass HTM auf Objekte in einem Datenbankverwaltungssystem (DBMS) angewendet wird. Vorhandene Datenbankobjekte können beispielsweise um eine kleine Datenstruktur (z.B. Tag und Metadaten) erweitert werden, die zum Beschreiben der Zugriffsabsicht (access intent) und des Status des Datenobjektes verwendet werden kann. Dieses Datenobjekt kann beispielsweise eine Tabelle, eine Datei für eine Tabellenpartition, ein Eintrag (z.B. innerhalb einer Seite oder als Verweis auf eine andere Seite (cross-page)) oder eine Seite usw. sein. Wird ein Datenobjekt erweitert, kann es als „getaggte Daten“ („tagged data“) bezeichnet werden. Auf Anwendungsebene können eine oder mehrere APIs festgelegt werden, die so konfiguriert sein können, dass sie eine Transaktionsdeklaration (transaction declaration) auf „getaggten Daten“ aktivieren. Verfahren zum Implementieren der APIs können so bereitgestellt werden, dass deklarierte Transaktionen von „getaggten Daten“ für Anwendungen transparent und auf folgende Weise ausgeführt werden. Das Privileg des Zugriffs auf ein Datenobjekt kann nach erfolgreichen Aktualisierungen an seinem „Tag“ gewährt werden, wobei der „Tag“-Aktualisierungsprozess optimistisch mittels HTM ausgeführt und verwaltet werden kann. Nach erfolgreichem Reservieren des Zugriffsprivilegs kann lock-frei auf das Datenobjekt zugegriffen werden. Der Zugriff auf mehrere Datenobjekte kann behandelt werden, indem diese in einer gemeinsam deklarierten Transaktion (common declared transaction) gruppiert werden, wie beispielsweise jene, die in den hierin beschriebenen APIs auf Anwendungsebene bereitgestellt sind. Die Datenobjektgruppen können mittels HTM optimistisch bei lock-freiem Zugriff als Gruppe verarbeitet werden.

Transaktionsprozesse, die gemäß dem Stand der Technik entwickelt wurden, können Concurrency Control an großen Datenobjekten nicht angemessen behandeln, insbesondere wenn HTM verwendet wird. Wie dies vorstehend hierin beschrieben wurde, können Ausführungsformen dieses Problem angehen, indem Transaktionsprozesse bereitgestellt werden, die so konfiguriert sind, dass sie ohne Lock-Manager arbeiten. Eine entsprechende Datenstruktur (z.B. ein Baum, eine Datenseite, ein Dokument) kann bei Deklarierung (upon declaration) erweitert werden. An der Erweiterung können beispielsweise Transaktions-Tag-Zähler beteiligt sein, die von dem Compiler der Programmiersprache verwendet werden, wobei ein Zähler für Zählungen aktiver Leseoperationen („active read“) und ein weiterer Zähler für aktive Schreiboperationen („active write“) zum aktuellen Zeitpunkt („current time“) auf der Datenstruktur vorhanden sein können. Alternativ dazu kann der Zähler für aktive Leseoperationen aus einem oder mehreren Bits bestehen. Diese Zähler können als Transaktions-Tag der Datenstruktur bezeichnet werden.

In den 4A bis 4C werden beispielhafte APIs und dazugehörige Implementierungen gemäß Ausführungsformen dargestellt. Deklarationen wie jene, die in den 4A bis 4C dargestellt sind, können so erweitert werden, dass sie mehrere diskrete Objekte (wie beispielsweise eine Datenseite und eine Indexseite in einer Datenbank) und eine „logische Dateneinheit“ („logic data unit“) wie jene, die in 5 darunter dargestellt ist und mit einem Tag erweitert wird, behandeln. Darüber hinaus lassen die Ausführungsformen möglicherweise eine Anwendung zum Gruppieren von Objekten bei einer Transaktionsgranularität zu. Die in den 5A bis 5C dargestellten beispielhaften APIs veranschaulichen Transaktionen an einzelnen Objekten, während die nachfolgenden 5A bis 5C Transaktionen an mehreren Objekten darstellen.

In den 5A und 5B werden APIs dargestellt, die gemäß Ausführungsformen konfiguriert sind. 5A stellt eine API für Tagged_Tx_begin dar, und 5B stellt eine API für Tagged_Tx_end dar, die für Datenzugriffstransaktionen an getaggten Datenstrukturen verwendet werden können. Unter Verwendung der Ausführungsformen kann ein Compiler oder ein Language Interpreter eine Transaktion Tagged_Tx_begin und Tagged_Tx_end in eine Operation umwandeln, die sich aus Folgendem zusammensetzt: (1) Bevor ein Datenelement (des Datenstrukturtyps) gelesen oder aktualisiert wird, kann sein Transaktions-Tag aktualisiert werden; (2) zum Bearbeiten der Aktualisierungen der Transaktions-Tags kann HTM verwendet werden; (3) führt ein Thread ein Commit zu (1) und (2) aus, ist er zum Aktualisieren oder Lesen von Inhalt der Datenstruktur ohne Transaktion („transaction free“) berechtigt; (4) bei Abschluss von (1) kann das Transaktions-Tag des Datenelementes entsprechend zurückaktualisiert werden. Darüber hinaus ermöglichen Ausführungsformen, dass, wenn eine Anwendung am Ende ein Rollback ausgibt, die Protokolleinträge zum „Rückgängigmachen“ („un-do log records“) des vorhandenen DBMS zum Wiederholen der Datenzugriffstransaktionen an getaggten Datenstrukturen auf die hierin beschriebene Weise verwenden können, womit die Datenaktualisierungsoperationen umgekehrt werden.

Gemäß Ausführungsformen können die vorstehend beschriebenen Schritte (1) bis (4) so erweitert werden, dass eine Transaktion behandelt wird, die sich aus einer Mischung aus kleinen, nicht getaggten Datenobjekten und großen, getaggten Datenobjekten zusammensetzt. Für Datenbankanwendungen kann damit die Fähigkeit zum Gruppieren diskreter Datenobjekte, wie beispielsweise eines Satzes von Seiten, in einen Transaktionsumfang nach dem Alles-oder-Nichts-Prinzip bereitgestellt werden. Obgleich eine solche Konfiguration im Hinblick auf Datenaktualisierung tatsächlich eher einem Blockierungsmechanismus entspricht, müssen, verglichen mit einem Mechanismus wie beispielsweise Sperren (Locking) oder Latching, keine Verklemmungen (dead locks) oder eine „dead-latch situation“ befürchtet werden. Es besteht des Weiteren keine Notwendigkeit zum Aufsuchen von Sperr-Tabellen (lock tables).

Anwendungen können versuchen, auf nicht festgeschriebene Daten („uncommitted data) (z.B. „dirty“ (genutzt)) zuzugreifen. So kann ein Leser beispielsweise versuchen, nicht festgeschriebene Daten zu lesen. Zum Bearbeiten von nicht festgeschriebenen Daten können Ausführungsformen zusätzliche APIs und dazugehörige Implementierungen bereitstellen, einschließlich APIs für „update“ (Aktualisieren) und „dirty_read“. So kann für eine Aktualisierungsoperation an einem logischen Objekt, das auf mehreren Daten-/Indexseiten abgebildet (mapped) wird, eine Übersetzungs- und Ausführungsfunktion bereitgestellt werden, um bestimmte APIs in eine HW-Transaktion („tx_“) zu übersetzen, die Schreibzugriff auf alle Unterobjekt-Tags (sub-object tags) des logischen Objektes (z.B. eine zusätzliche Hierarchie) erfordert. Eine beispielhafte update-API kann wie folgt konfiguriert sein:

      Tagged_Update_Tx_begin;
             Aktualisierung a & b -- a & b gehören zum selben logischen Objekt
      Tagged_Update_Tx_end.

Die update-API kann folgendermaßen zur Ausführung übersetzt werden:

      Tx_begin;
             wenn (a_read_count > 0 oder b_read_count > 0 oder a_write_count=1
             oder 



             b_write_count=1) verwerfen (abort);
      ansonsten
             a_write_count =1;
             b_write_count =1;
      Tx_end;
      wenn (TX_commit)
             a aktualisieren
             b aktualisieren
      ansonsten erneut versuchen (re-try);
      Tx_begin;
             a_write_count = 0;
             b_write_count = 0;
      Tx_end;

Für eine „dirty read“-API kann die Gruppe aus logischen Objekten in einzelne kleinere Unterobjekt-Transaktionen (sub-object transactions) aufgeteilt werden, während ein Tag pro Objekt beibehalten wird, so dass Datenkonsistenz auf der Ebene des einzelnen Objektes aufrechterhalten wird. Eine beispielhafte „dirty read“-API kann folgendermaßen konfiguriert sein:

      Tagged_Dirty_read_Tx_begin;
             a lesen;
             b lesen;
      Tagged_Dirty_Read_Tx_end;

Die dirty read-API kann folgendermaßen zur Ausführung konfiguriert sein:

      Tx_begin;
             wenn (a_write_count <>0) verwerfen
             ansonsten a_read_count ++;
      Tx_end;
      wenn (TX_commit)
             a lesen
      ansonsten a erneut versuchen oder b versuchen. 



      Tx_begin;
             wenn (b_write_count <>0) verwerfen
             ansonsten b_read_count ++;
      Tx_end;
      wenn (TX_commit)
             b lesen

ansonsten erneut versuchen (re-try) oder zurückgehen (go back), falls es noch nicht gelesen wurde.

Datenobjekte können als Hierarchie bearbeitet werden. So kann beispielsweise für eine Datenbank eine Hierarchie aus Objekten von oben nach unten Tabellen-, Seiten- und Zeilenobjekte enthalten. Darüber hinaus können Objekte in einer Hierarchie auf der Grundlage von einem lokalen oder globalen Status kategorisiert werden. Dementsprechend können Ausführungsformen zusätzliche Tags bereitstellen, um eine Blockierung auf Hierarchieebene (Hierarchy Level Blocking) zu unterstützen. Im Sinne eines nicht einschränkenden Beispiels können Ausführungsformen table_global_write-Tags und table_global_read-Tags bereitstellen, und gemäß diesem Beispiel können noch weitere Tags bereitgestellt werden: table_local_write / table_local_read; page_global_write / page_global_read; und page_local_write / page_local_read. Hierarchy Level Blocking kann gemäß Ausführungsformen so konfiguriert sein, dass Operationen, unter anderem Aktualisieren von lokalen Tags durch lokalen Zugriff, Überprüfen von globalen Tags durch lokalen Zugriff sowie Überprüfen und Aktualisieren von globalen Tags durch globalen Zugriff, unterstützt werden.

Hierarchy Level Blocking kann so konfiguriert sein, dass es mit einer groberen Granularität arbeitet. Beispielsweise können unter Verwendung von HTM (anstelle von Latching) Drain- und Claim-Tags für eine Tabelle an einem zentralen Ort bereitgestellt und verwaltet werden. Gemäß Ausführungsformen kann Hierarchy Locking jedoch auch durch Festlegen eines bestimmten Satzes an Tags konfiguriert werden. Für eine Tabelle oder eine Partition können die folgenden Tags festgelegt werden: (1) table_global_write_count zum Erteilen von Tabellensperren (table level locking) und zum Sperren weiterer Tabellensperr-Threads (table level locking threads); (2) table_global_intent_write_count, das zum Entleeren (drain) aller Seitenschreibvorgänge (page level writes) verwendet werden kann, so dass ein Dienstprogramm schließlich dann Zugriff erhalten kann, wenn eine Tabellensperre (table level lock) beabsichtigt ist; (3) table_local_write_count, das so konfiguriert sein kann, dass eine Tabellensperre (table level locking) nur dann erteilt wird, wenn sein Wert beim Aktualisieren von Seiten 0 erreicht; (4) table_read_count; und (5) table_page_read_count. Auf Seitenebene kann jede Seite table_global_write_count-Tags und table_global_intent_write_count-Tags aufweisen, die so konfiguriert sind, dass sie neue Anforderungen zum Aktualisieren von Seiten blockieren, wenn sie auf einen Wert gesetzt sind, der nicht Null beträgt. Darüber hinaus können alle Schreibvorgänge auf Seitenebene oder auf Zeilenebene so konfiguriert sein, dass sie ein table_local_write_count-Tag aktualisieren, beispielsweise durch Erhöhen des Tag vor und durch Vermindern des Tag nach einem Schreibvorgang. Da HTM oftmals bei Cachezeilen-Granularität funktioniert, können Tags verteilt werden (z.B. mittels Hashing), um am selben Ort vorhandene Tags, die in derselben Cachezeile von unterschiedlichen Transaktionen berührt werden, statistisch zu minimieren.

Kurz zusammengefasst, können Ausführungsformen so konfiguriert sein, dass sie Prozesse zum Behandeln von Datenbanktransaktionen (einschließlich verschachtelter Transaktionen) unter Verwendung von HTM und einer Laufzeit-Implementierung bei einer oder mehreren APIs bereitstellen. So können die APIs beispielsweise transparent sein und Datenbankobjekten Tags oder Annotationen hinzufügen. Eine Anwendung kann auf der Grundlage von erfolgreicher HTM-Ausführung und Annahme der Statusänderungen (die nach Abschluss des Zugriffs wieder rückgängig gemacht werden können) von annotierten Objekten auf Transaktionsobjekte zugreifen, wobei der Zugriff entweder gewährt oder abgelehnt wird. Wird ein Zugriff gewährt, darf damit eine Anwendung Objekte aktualisieren oder lesen, und wird ein Zugriff verweigert, darf eine Anwendung nicht auf ein bestimmtes Objekt zugreifen. Gemäß Ausführungsformen kann der Zugriff auf Gruppen von Objekten nach dem Alles-oder-Nichts-Prinzip gewährt werden. Wird beispielsweise der Umfang einer Gruppe als Satz von Objekten definiert, kann auf diese Objekte in der Gruppe gemäß einem Alles-oder-Nichts-Prinzip zugegriffen werden.

In Bezug auf 6 ist offensichtlich, dass bestimmte Ausführungsformen unter Verwendung einer beliebigen von einer breiten Vielfalt von Einheiten oder von Kombinationen aus Einheiten implementiert werden können. Eine beispielhafte Einheit, die zum Implementieren von Ausführungsformen verwendet werden kann, weist eine Datenverarbeitungseinheit in Form eines Computers 610 auf, der als Server, Workstation-Computer, mobile Einheit und Ähnliches ausgebildet sein kann. In dieser Hinsicht kann der Computer 610 Programmanweisungen ausführen, die so konfiguriert sind, dass sie eine Vorhersageplatzierung (predictive placement) durch Netzwerkanalyse bereitstellen und weitere Funktionen der Ausführungsformen in ihrer hierin beschriebenen Form ausführen.

Zu Komponenten des Computers 610 gehören, ohne darauf beschränkt zu sein, wenigstens eine Verarbeitungseinheit 620, ein Systemspeicher 630 und ein Systembus 622, der verschiedene Systemkomponenten, unter anderem den Systemspeicher 630, mit der oder den Verarbeitungseinheit/en 620 verbindet. Der Computer 610 kann verschiedene computerlesbare Medien aufweisen beziehungsweise Zugriff darauf haben. Der Systemspeicher 630 kann computerlesbare Speichermedien in Form von flüchtigem und/oder nichtflüchtigem Speicher wie beispielsweise Nur-Lese-Speicher (ROM) und/oder Arbeitsspeicher (RAM) aufweisen. Im Sinne eines Beispiels und nicht als Beschränkung kann der Systemspeicher 630 des Weiteren ein Betriebssystem, Anwendungsprogramme, weitere Programmmodule und Programmdaten aufweisen.

Ein Benutzer kann über Eingabeeinheiten 640 (beispielsweise durch Eingabe von Befehlen und Daten) eine Schnittstelle mit dem Computer 610 bilden. Ein Monitor oder ein anderer Typ von Einheit kann über eine Schnittstelle 650, beispielsweise eine Ausgabeschnittstelle, ebenfalls mit dem Systembus 622 verbunden sein. Zusätzlich zu einem Monitor können Computer auch andere Peripherie-Ausgabeeinheiten aufweisen. Der Computer 610 kann in einer vernetzten oder einer verteilten Umgebung unter Verwendung logischer Verbindungen (Netzwerkschnittstelle 660) zu anderen fernen Computern oder Datenbanken (ferne Einheit(en) 670) arbeiten. Zu den logischen Verbindungen können ein Netzwerk wie beispielsweise ein Lokalnetz (LAN), ein Weitverkehrsnetz (WAN), ein zellulares Netz oder auch andere Netzwerke gehören.

Claims

System zum Ausführen von Datenbanktransaktionen, aufweisend: wenigstens einen Prozessor; und eine Speichereinheit mit einem Hardware-transaction-memory- (HTM-) Speicher, die funktionell mit dem wenigstens einen Prozessor verbunden ist; wobei als Reaktion auf eine Ausführung von Programmanweisungen, auf die der wenigstens eine Prozessor zugreifen kann, der wenigstens eine Prozessor so konfiguriert ist, dass er die Schritte ausführt: Annotieren wenigstens eines auf einer Datenverarbeitungseinheit vorhandenen Datenobjektes unter Verwendung wenigstens eines Transaktions-Tags, um dessen Verfügbarkeit anzuzeigen, wobei ein Transaktions-Tag-Zähler aktive Leseoperationen und ein Transaktions-Tag-Zähler aktive Schreiboperationen zum aktuellen Zeitpunkt bei dem Datenobjekt zählt; Verarbeiten wenigstens einer Datenbanktransaktion, wobei das Verarbeiten umfasst: Aktualisieren des Transaktions-Tag-Zählers des wenigstens einen Datenobjekts zum Reservieren eines Zugriffsprivilegs auf das wenigstens eine Datenobjekt und Setzen des HTM-Status des wenigstens einen Datenobjekts auf „lock-free“-, Aktualisieren des HTM-Status des wenigstens einen Datenobjektes als Reaktion auf einen versuchten Zugriff auf das wenigstens eine Datenobjekt durch die wenigstens eine Datenbanktransaktion, wobei das Aktualisieren des HTM-Status ein Modifizieren des wenigstens einen Datenobjekts durch Markieren als zugegriffen enthält.
System nach Anspruch 1, wobei der wenigstens eine Prozessor des Weiteren so konfiguriert ist, dass er wenigstens eine Anwendungsprogrammierschnittstelle definieren kann, die so konfiguriert ist, dass sie eine Transaktionsdeklaration an Daten, die mit einem Transaktions-Tag annotiert sind, aktivieren kann.
System nach Anspruch 1, wobei der Status des wenigstens einen Datenobjektes mittels Hardware-Transaktionsverwaltung aktualisiert wird.
System nach Anspruch 3, wobei Hardware-Transaktionsverwaltung ein Aktualisieren optimistisch „lock-frei“ behandelt.
System nach Anspruch 1, wobei das wenigstens eine Transaktions-Tag einen Zähler für aktive Leseoperationen und einen Zähler für aktive Schreiboperationen aufweist.
System nach Anspruch 1, wobei das wenigstens eine Transaktions-Tag für Anwendungen mit Datenbanktransaktionen transparent ist.
System nach Anspruch 1, wobei das Aktualisieren des Status des wenigstens einen Datenobjektes als Reaktion auf den Abschluss des Zugriffs auf das wenigstens eine Datenobjekt rückgängig gemacht wird.
System nach Anspruch 1, wobei ein Zugriff auf eine Vielzahl von Datenobjekten gruppiert werden kann.
System nach Anspruch 1, wobei ein Zugriff auf eine gruppierte Vielzahl von Datenobjekten auf der Grundlage eines Alles-oder-Nichts-Prinzips gewährt wird.
System nach Anspruch 1, wobei das wenigstens eine Datenobjekt innerhalb einer Datenbank definiert wird, die Tabellen-, Seiten- und Zeilenelemente aufweist.
Verfahren zum Ausführen von Datenbanktransaktionen mit einem Hardware-transaction-memory- (HTM-) Speicher, das die Schritte umfasst: Annotieren wenigstens eines auf einer Datenverarbeitungseinheit vorhandenen Datenobjektes unter Verwendung wenigstens eines Transaktions-Tags, um dessen Verfügbarkeit anzuzeigen, wobei ein Transaktions-Tag-Zähler aktive Leseoperationen und ein Transaktions-Tag-Zähler aktive Schreiboperationen zum aktuellen Zeitpunkt bei dem Datenobjekt zählt; Verarbeiten wenigstens einer Datenbanktransaktion, wobei das Verarbeiten umfasst: Aktualisieren des Transaktions-Tag-Zählers des wenigstens einen Datenobjekts zum Reservieren eines Zugriffsprivilegs auf das wenigstens eine Datenobjekt und Setzen des HTM-Status des wenigstens einen Datenobjekts auf „lock-free“-, Aktualisieren des HTM-Status des wenigstens einen Datenobjektes als Reaktion auf einen versuchten Zugriff auf das wenigstens eine Datenobjekt durch die wenigstens eine Datenbanktransaktion, wobei das Aktualisieren des HTM-Status ein Modifizieren des wenigstens einen Datenobjekts durch Markieren als zugegriffen enthält.
Verfahren nach Anspruch 11, bei dem jedes Datenbankobjekt eine Datenstruktur zum Anzeigen des Status des Datenbankobjekts und einer Zugriffsabsicht aufweist, wobei die Datenstruktur das Transaktions-Tag und Metadaten umfasst.
Computerprogrammprodukt, aufweisend: ein computerlesbares Speichermedium mit darin enthaltenem computerlesbarem Programmcode, wobei der computerlesbare Programmcode aufweist: computerlesbaren Programmcode, der so konfiguriert ist, dass er das Verfahren nach Anspruch 11 oder 12 ausführt.