Cet article étudie principalement tous les contenus des verrous pessimistes hibernate et des serrures optimistes, comme détaillé ci-dessous.
Le verrouillage pessimiste est généralement mis en œuvre par le mécanisme de la base de données. Pendant l'ensemble du processus, les données sont verrouillées (lors de la requête). Tant que les choses ne sont pas publiées (commit / rollback), aucun utilisateur ne peut le visualiser ou le modifier.
Expliquons-le à travers un cas ci-dessous.
Cas: Supposons que l'inventaire des marchandises soit de 1000, et lorsque le comptable 1 supprime les données et se prépare à la modification, mais il y a quelque chose de temporaire, il part. Au cours de cette période, la comptabilité 2 a extrait les données et soustrait la quantité de 200, puis la comptabilité 1 est revenue et a soustraité la quantité qui vient d'être supprimée par 200. Cela a causé un problème. La comptabilité 1 n'a apporté aucune modification basée sur 800. C'est ce qu'on appelle la perte de mise à jour, et elle peut être résolue à l'aide de verrous pessimistes.
Inventory.java:
Classe publique Inventaire {/ * Numéro d'inventaire * / Private String itemNo; / * Nom de l'inventaire * / Private String itemName; / * Quantité d'inventaire * / quantité int privée; // omettre les méthodes de setter et de getter}Inventaire.hbm.xml:
<? xml version = "1.0"?> <! Doctype Hibernate-Mapping public "- // Hibernate / Hibernate Mapping Dtd 3.0 // en" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <HiberNate-Mapping> <Class Name = "Com.Lixue.ban.ban.inventory" table = "t_inventory"> <! - Affectation manuelle de la clé primaire -> <id name = "itemno"> <générateur // id> <! - Propriétés de mappage -> <propriété name = "itemname" /> <propriété name = "Quantity" /> </ class> </ Hibernate-mapping>
Classe de test:
Le comptable 1 charge les données via le verrouillage pessimiste et modifie les données!
public void testload1 () {session session = null; essayez {session = hibernateutils.getSession (); session.begintransaction (); / * Un verrou pessimiste est ajouté lors du chargement, ce qui rend impossible pour les autres utilisateurs d'accéder * / inventaire inv = (inventory) session.load (inventory.class, "1001", LockMode.upgrade); / * Obtenir des données * / System.out.println ("Opt1 -> itemNo =" + inv.getItemno ()); System.out.println ("Opt1 -> itemName =" + inv.getItemName ()); System.out.println ("Opt1 -> Quantity =" + inv.getquantity ()); / * Quantité moins 200 * / inv.setquantity (inv.getquantity () - 200); session.getTransaction (). commit (); } catch (exception e) {e.printStackTrace (); session.getTransaction (). Rollback (); } enfin {hibernateUtils.closeSession (session); }}Le comptable 2 et le comptable 1 ont les mêmes opérations, et les deux modifient les données dans la base de données!
public void testload2 () {session session = null; essayez {session = hibernateutils.getSession (); session.begintransaction (); / * Ajouter un verrouillage lors du chargement des données, afin que d'autres ne puissent pas obtenir de données * / Inventory inv = (Inventory) session.load (Inventory.class, "1001", LockMode.upgrade); / * Obtenez les données réelles * / System.out.println ("Opt2 -> itemno =" + inv.getItemno ()); System.out.println ("Opt2 -> itemName =" + inv.getItemName ()); System.out.println ("Opt2 -> Quantity =" + inv.getquantity ()); / * Inventaire moins 200 * / inv.setquantity (inv.getquantity () - 200); session.getTransaction (). commit (); } catch (exception e) {e.printStackTrace (); session.getTransaction (). Rollback (); } enfin {hibernateUtils.closeSession (session); }}Remarque: Les opérations effectuées par les deux comptables sont les mêmes. Si un verrou pessimiste est ajouté, le comptable supprime les données et modifie les données. Avant que le comptable 1 ne soumet la chose, le comptable 2 ne peut pas accéder aux données et ne peut être que dans un état d'attente. Ce n'est qu'après avoir su que le comptable 1 a soumis la chose, le comptable 2 a la possibilité de fonctionner sur les données de la base de données.
Grâce à l'étui de verrouillage pessimiste ci-dessus, nous pouvons constater que le plus grand avantage du verrouillage pessimiste est qu'il peut empêcher la perte de mise à jour. Lorsque la calculatrice 1 traite les données, la calculatrice 2 ne peut être que dans un état d'attente. Ce n'est qu'après que la calculatrice 1 soumet la chose, la calculatrice 2 a la possibilité de modifier les données. Mais il y a aussi un gros problème, c'est-à-dire que si le comptable 1 interroge les données et part, les autres devront attendre la majeure partie de la journée, ce qui est une perte de temps. Afin de résoudre ce problème, nous pouvons utiliser des verrous optimistes.
Les verrous optimistes ne sont pas des verrous dans le vrai sens. Dans la plupart des cas, ils sont mis en œuvre sous la forme d'une version de données. Généralement, un champ de version est ajouté à la base de données et la version est lue lors de la lecture des données. Lors de l'enregistrement des données, il détermine si la valeur de version est inférieure à la valeur de version de la base de données. S'il est moins, il ne sera pas mis à jour, sinon il sera mis à jour.
Les paramètres Javabean sous verrous optimistes, Inventory.java:
Classe publique Inventaire {/ * Numéro d'inventaire * / Private String itemNo; / * Nom de l'inventaire * / Private String itemName; / * Quantité d'inventaire * / quantité int privée; / * Version de données * / version int privé; // omettre les méthodes de setter et de getter}Inventaire.hbm.xml:
<? xml version = "1.0"?> <! Doctype Hibernate-Mapping public "- // Hibernate / Hibernate Mapping Dtd 3.0 // en" "http://hibernate.sourcefor.twnet/hibernate-mapping-3.0.dtd"> <Hibernate-Mapping> <! Confiance -> <class name = "com.lixue.bean.inventory" table = "t_inventory" optimiste-Lock = "version"> <! - Mapping de clé primaire -> <id name = "itemno"> <générateur /> </ id> <! - Data version, doit être à l'emplacement après la clé primaire -> <version Name = "version" /> <! name = "Quantity" /> </ Class> </ Hibernate-Mapping>
Remarque: Le fichier de mappage utilisant des verrous optimistes stipule que le mappage du champ de version doit être mappé d'abord après l'ID de clé primaire.
Le comptable 1 traite les données dans une situation de verrouillage optimiste:
public void testload1 () {session session = null; essayez {session = hibernateutils.getSession (); session.begintransaction (); / * Chargez les données sous verrouillage optimiste * / Inventory inv = (Inventory) session.load (Inventory.class, "1001"); / * Real Data Acquisition * / 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 -> Quantity =" + inv.getquantity ()); / * Quantité moins 200 * / inv.setquantity (inv.getquantity () - 200); session.getTransaction (). commit (); } catch (exception e) {e.printStackTrace (); session.getTransaction (). Rollback (); } enfin {hibernateUtils.closeSession (session); }}Le comptable 2 traite les données sous verrouillage optimiste (le comptable 2 peut traiter les données sans les soumettre)
public void testload2 () {session session = null; essayez {session = hibernateutils.getSession (); session.begintransaction (); / * Chargez les données sous verrouillage optimiste * / Inventory inv = (Inventory) session.load (Inventory.class, "1001"); / * Real Data Acquisition * / 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 -> Quantity =" + inv.getquantity ()); / * Quantité moins 200 * / inv.setquantity (inv.getquantity () - 200); session.getTransaction (). commit (); } catch (exception e) {e.printStackTrace (); session.getTransaction (). Rollback (); } enfin {hibernateUtils.closeSession (session); }}Remarque: Dans le principe que le comptable supprime les données et soustrait le numéro de 200 et ne les soumet pas, le comptable 2 peut également faire fonctionner les données. Ceci est différent du verrou pessimiste. Lorsque le comptable 2 exploite les données et les soumet, la version de la version de données dans la base de données sera ajoutée par 1. Ensuite, lorsque le comptable 1 reviendra pour soumettre la chose, un message d'erreur apparaîtra que les données ont été mises à jour, veuillez les recharger.
Les serrures pessimistes affecteront une concurrence élevée, il est donc préférable d'utiliser des serrures optimistes.
Ce qui précède est toute l'explication détaillée de la verrouillage pessimiste hibernate et des exemples de verrouillage optimiste dans cet article. J'espère que ce sera utile à tout le monde. Les amis intéressés peuvent continuer à se référer à d'autres sujets connexes sur ce site. S'il y a des lacunes, veuillez laisser un message pour le signaler. Merci vos amis pour votre soutien pour ce site!