Dieser Artikel untersucht hauptsächlich alle Inhalte von Pessimistischen Schlössern und optimistischen Schlössern, wie nachstehend beschrieben.
Die pessimistische Verriegelung wird normalerweise vom Datenbankmechanismus implementiert. Während des gesamten Vorgangs sind die Daten gesperrt (bei Abfrage). Solange die Dinge nicht veröffentlicht werden (Commit/Rollback), kann kein Benutzer es anzeigen oder ändern.
Erklären wir es durch einen Fall unten.
Fall: Angenommen, das Inventar der Waren beträgt 1000, und wenn der Buchhalter 1 die Daten herausnimmt und sich auf die Änderung vorbereitet, aber es gibt etwas vorübergehendes, verlässt er. In diesem Zeitraum extrahierte die Buchhaltung 2 die Daten und subtrahierte die Menge um 200, und dann kam die Buchhaltung 1 zurück und subtrahierte die gerade durch 200 entferntes Mengen. Dies verursachte ein Problem. Die Bilanzierung 1 hat keine Änderungen auf der Grundlage von 800 vorgenommen. Dies wird als Aktualisierungsverlust bezeichnet und kann durch Verwendung pessimistischer Schlösser gelöst werden.
Inventory.java:
public class Inventory { /* Inventarnummer* / private Zeichenfolge itemno; /* Bestandsname*/ private Zeichenfolge itemname; /* Inventarmenge*/ private int -Menge; // Setter- und Getter -Methoden weglassen}Inventory.hbm.xml:
<? table = "t_inventory"> <!-Manuelle Zuweisung von Primärschlüssel-> <id name = "itemno"> <generator // id> <!-Mapping-Eigenschaften-> <Eigenschaft name = "itemname"/> <Eigenschaft name = "Quantität"/> </class> </hibernate-mapping>
Testklasse:
Buchhalter 1 lädt Daten durch pessimistisches Sperren und modifiziert die Daten!
public void testload1 () {session session = null; try {session = hibernateUtils.getSession (); Sitzung.BeginTransaction (); /*Eine pessimistische Sperre wird beim Laden hinzugefügt, sodass es anderen Benutzern unmöglich ist, auf zuzugreifen*/ Inventory inv = (Inventory) Session /*Daten abrufen*/ system.out.println ("opt1-> itemno =" + inv.getitemno ()); System.out.println ("opt1-> itemname =" + inv.getitemname ()); System.out.println ("opt1-> mantity =" + inv.getQuantity ()); /*Menge minus 200*/ inv.setquantity (inv.getQuantity () - 200); Session.Gettransaction (). commesent (); } catch (Ausnahme e) {e.printstacktrace (); Session.Gettransaction (). Rollback (); } endlich {HibernateUtils.Closession (Sitzung); }}Accountant 2 und Accountant 1 haben die gleichen Vorgänge und beide ändern die Daten in der Datenbank!
public void testload2 () {session session = null; try {session = hibernateUtils.getSession (); Sitzung.BeginTransaction (); /*Fügen Sie beim Laden von Daten eine Sperre hinzu, damit andere keine Daten erhalten können /*Die realen Daten erhalten*/ system.out.println ("opt2-> itemno =" + inv.getitemno ()); System.out.println ("opt2-> itemname =" + inv.getitemname ()); System.out.println ("opt2-> mantity =" + inv.getQuantity ()); /*Inventory minus 200*/ inv.setquantity (inv.getQuantity () - 200); Session.Gettransaction (). commesent (); } catch (Ausnahme e) {e.printstacktrace (); Session.Gettransaction (). Rollback (); } endlich {HibernateUtils.Closession (Sitzung); }}HINWEIS: Die von den beiden Buchhaltern ausgeführten Operationen sind gleich. Wenn eine pessimistische Sperre hinzugefügt wird, nimmt der Buchhalter die Daten heraus und modifiziert die Daten. Bevor Accountant 1 das Ding einreicht, kann Buchhalter 2 auf die Daten nicht zugreifen und nur in einem Wartezustand sein. Erst nachdem Accountant 1 das Ding eingereicht hat, hat Accountant 2 die Möglichkeit, die Daten in der Datenbank zu betreiben.
In dem obigen pessimistischen Lock -Fall können wir feststellen, dass der größte Vorteil des pessimistischen Schlosses darin besteht, dass der Verlust von Aktualisierungen verhindern kann. Wenn Taschenrechner 1 verarbeitet werden, kann der Rechner 2 nur in einem Wartezustand sein. Erst nach dem Rechnungsgeräte 1 hat Taschenrechner 2 die Möglichkeit, die Daten zu ändern. Aber es gibt auch ein großes Problem, das heißt, wenn der Buchhalter 1 die Daten und Blätter abfragt, müssen die anderen den größten Teil des Tages warten, was eine sehr Zeitverschwendung ist. Um dieses Problem zu lösen, können wir optimistische Sperren verwenden.
Optimistische Schlösser sind keine Schlösser im wahren Sinne. In den meisten Fällen werden sie in Form einer Datenversion implementiert. Im Allgemeinen wird der Datenbank ein Versionsfeld hinzugefügt, und die Version wird beim Lesen der Daten vorgelesen. Beim Speichern der Daten wird festgelegt, ob der Versionswert kleiner als der Versionswert der Datenbank ist. Wenn es weniger ist, wird es nicht aktualisiert, andernfalls wird es aktualisiert.
Die javabäischen Einstellungen unter optimistischen Schlössern, Inventory.java:
public class Inventory { /*Inventarnummer* / private Zeichenfolge itemno; /*Bestandsname*/ private Zeichenfolge itemname; /*Inventarmenge*/ private int -Menge; /*Datenversion*/ private int Version; // Setter- und Getter -Methoden weglassen}Inventory.hbm.xml:
<? Versionsverständnis-> <class name = "com.lixue.bean.inventory" table = "t_inventory" optimistic-lock = "Version"> <!-Primärschlüssel Mapping-> <id name = "itemno"> <generator/> </id> <!-Datenversion, Muss am Standort nach dem primären Taste-> <files name = "Version"/> <! name = "quantity"/> </class> </hibernate-mapping>
HINWEIS: Die Mapping -Datei, die optimistische Sperren mit optimistischem Sperren enthält, sieht vor, dass die Zuordnung des Versionsfelds zuerst nach der primären Schlüssel -ID zuerst abgebildet werden muss.
Buchhalter 1 verarbeitet Daten in einer optimistischen Sperrsituation:
public void testload1 () {session session = null; try {session = hibernateUtils.getSession (); Sitzung.BeginTransaction (); /*Daten unter optimistische Sperre laden*/ Inventory inv = (Inventory) Sitzung.load (Inventory.Class, "1001"); /*Reale Datenerfassung*/ system.out.println ("opt1-> itemno =" + inv.getitemno ()); System.out.println ("opt1-> itemname =" + inv.getitemname ()); System.out.println ("opt1-> Version =" + inv.getversion ()); System.out.println ("opt1-> mantity =" + inv.getQuantity ()); /*Menge minus 200*/ inv.setquantity (inv.getQuantity () - 200); Session.Gettransaction (). commesent (); } catch (Ausnahme e) {e.printstacktrace (); Session.Gettransaction (). Rollback (); } endlich {HibernateUtils.Closession (Sitzung); }}Accountant 2 verarbeitet Daten unter optimistisches Sperren (Buchhalter 2 kann Daten verarbeiten, ohne sie zu senden)
public void testload2 () {session session = null; try {session = hibernateUtils.getSession (); Sitzung.BeginTransaction (); /*Daten unter optimistische Sperre laden*/ Inventory inv = (Inventory) Sitzung.load (Inventory.Class, "1001"); /*Reale Datenerfassung*/ system.out.println ("opt2-> itemno =" + inv.getitemno ()); System.out.println ("opt2-> itemname =" + inv.getitemname ()); System.out.println ("opt2-> Version =" + inv.getversion ()); System.out.println ("opt2-> mantity =" + inv.getQuantity ()); /*Menge minus 200*/ inv.setquantity (inv.getQuantity () - 200); Session.Gettransaction (). commesent (); } catch (Ausnahme e) {e.printstacktrace (); Session.Gettransaction (). Rollback (); } endlich {HibernateUtils.Closession (Sitzung); }}Hinweis: Unter der Prämisse, dass der Buchhalter die Daten herausnimmt und die Nummer nach 200 subtrahiert und sie nicht übermittelt, kann der Buchhalter 2 auch die Daten betreiben. Dies unterscheidet sich von pessimistischem Schloss. Wenn der Buchhalter 2 die Daten betreibt und sie einreicht, wird die Datenversion in der Datenbank um 1 hinzugefügt. Wenn der Buchhalter 1 zurückkommt, um das Ding zu senden, wird eine Fehlermeldung angezeigt, dass die Daten aktualisiert wurden, bitte laden Sie es neu.
Pessimistische Schlösser beeinflussen eine hohe Parallelität, daher ist es besser, optimistische Schlösser zu verwenden.
Das obige ist alle detaillierten Erklärungen für hibernate pessimistische Sperre und optimistische Sperrbeispiele in diesem Artikel. Ich hoffe, es wird für alle hilfreich sein. Interessierte Freunde können weiterhin auf andere verwandte Themen auf dieser Website verweisen. Wenn es Mängel gibt, hinterlassen Sie bitte eine Nachricht, um darauf hinzuweisen. Vielen Dank an Freunde für Ihre Unterstützung für diese Seite!