Minimierung der Tabelle Deadlock in meinem Szenario mit Oracle und InnoDB

Question

Ich habe 35 Funktionen, dass Update 1 bis 3 Tabellen, in einer Transaktion. Sie sind jedoch nicht nur Updates ausführen, aber sie tun Abfragen als auch.

• Tabelle 1 tut Reihe Update nur Aktionen, und einige Abfragen.
• Tabelle 2 tut Abfragen und Zeilenebene Aktualisierungen vorhandener Zeilen und manchmal löscht und fügt Zeilen. Tabelle 2 kann Abfragen innerhalb der Transaktion vor und nach der Reihe von Deletionen und Insertionen und oder Updates.
• Tabelle 3 tut Reihe Updates basierend auf den Ergebnissen der Tabelle 2 Aktionen über.

Meine erste Aktion zu machen sein wird, dass die Tabelle 3 aktualisieren alle am Ende getan.

In Tabelle 1 ist unabhängig von den anderen zwei Tabellen, und kann wahrscheinlich erste oder letzte sein. Also 2 Tabelle müssen Tabelle 3 Änderungen kommen vor.

Meine erste Sorge ist, dass mit Tabelle 2 Aktionen, ich Abfragen tun, dann Updates, dann mehr Abfragen, dann manchmal mehr aktualisiert. Muss ich zu Reorg meinen Code nicht, dies zu tun.

Meine zweite Sorge ist, dass Tabelle 3 ist die Tabelle, dass mit Servlet Threads schnell sein muss. Tabelle 3 ist für die einfachen Abfragen selbst verwendet. Aber es scheint, wie Zeilensperren werden diese Abfragen stoppen.

Wenn ich muß, kann ich den Tisch Wartungscode oben in einem einzigen Cluster weiten Prozess, von einem Thread beschrieben gesetzt. Die Geschwindigkeit des Updates spielt keine Rolle. Nur, dass die Abfragen gegen Tabelle 3 sind schnell. Und dass es nie ein toter Punkt.

Ich weiß nicht, Unterschiede zwischen Oracle und InnoDB, so dass ich Fragen dort. (Ich plane später Oracle zu aktualisieren.)

Im Grunde suche ich Zeiger über das, was zu achten. Natürlich könnte ich eine volle Tabellensperre auf Tabelle 2 erzwingen und dann Tabelle 3 am Anfang jeder Aktualisierungsfunktion, aber dann würde mein Table3 Servlet Abfrage Thread leiden. Also das scheint nicht wie eine Lösung.

Auch ich mache mir Sorgen um nur relativ zu dem Tisch 2 selbst, dass einige Funktionen Abfragen tun, Updates basierend auf der Abfrage, neue Abfragen auf der Update-basiert und weitere Updates dann einschließlich der Ergebnisse durch, um Updates zu Tabelle 3 fließt . Das scheint wirklich böse.

Empfehlungen? Andy

Es könnte sein, die gleichzeitigen Aktualisierungen die gleichen Reihen von zwei Tabellen, und ich habe auf die Tabellen mit dem Updates in der gleichen Reihenfolge zu treffen. Eine der Tabellen hat zwei Indizes, und scheint wie eine Tabellensperre den Index zu aktualisieren ist erforderlich? Einige der Funktionen Abfragetabelle 1, update Tabelle 1, dann optional Abfrage Tabelle 2, dann aktualisieren Tabelle 2, in einer Wiederholungsschleife. Diese Tabelle enthält alle der Eltern-Kind-Beziehungen in einem Baum alle meine Inhalte, so dass er hohe Volumen Aktualisierung für alle Nutzer ist.

Answer 1

Zum einen Abfragen in Oracle (und ich glaube, InnoDB) nehmen Sie nicht eine Sperre, wenn Sie FOR UPDATE verwenden.

Zweitens, bekomme ich keine Vorstellung von Ihrer Anwendung Skala. Wie viele gleichzeitige Transaktionen erwarten Sie haben? Erwarten Sie, dass sie die gleichen Zeilen zu aktualisieren?

Die Art der Anwendung, die von Deadlocks leiden könnte, ist eine Buchung oder Ticketing-System (zB Menschen, die versuchen die gleichen Sitze in einem Theater buchen), insbesondere in Hoch Gleichzeitigkeit Situationen (neue Show für die Buchung zur Verfügung steht).

Wenn Sie Anwendung dieses Profil passt, dann haben Sie wahrscheinlich wollen Deadlocksituationen antizipieren. Allerdings würde ich zumindest in Betracht zieht einfach den Fehler Trapping, Rollback und dann erneut versuchen, die Transaktion. Wenn Sie in mehr Details in Ihre Tabellenstrukturen gehen, Beziehungen und Update Kriterien, dann ein geeigneter Punkt zur Verriegelung kann deutlich werden.