Эта статья в основном изучает все содержимое пессимистических замков и оптимистичных замков, как подробно описано ниже.
Пессимистическая блокировка обычно реализуется с помощью механизма базы данных. В течение всего процесса данные заблокированы (при запросе). Пока вещи не выпущены (Commit/Oflback), ни один пользователь не может просмотреть или изменить его.
Давайте объясним это через случай ниже.
Случай: Предположим, что инвентарь товаров составляет 1000, и когда бухгалтер 1 берет данные и готовится к модификации, но есть что -то временное, он уходит. В течение этого периода бухгалтерский учет 2 извлекал данные и вычитал количество на 200, а затем бухгалтерский учет 1 вернулся и вычитал количество, только что удаленное на 200. Это вызвало проблему. Учет 1 не внес никаких изменений на основе 800. Это называется потерей обновлений, и его можно решить с помощью пессимистических замков.
Inventory.java:
Инвентаризация открытого класса { /* Номер инвентаризации* / private String itemno; /* Имя инвентаризации*/ private String ItemName; /* Количество инвентаризации*/ частное количество интенсивного количества; // Опустить методы установки и получения}Inventory.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 nely = "com.lixue.bean. TABLE = "T_INVENTORY"> <!-Ручное назначение первичной ключа-> <ID NAME = "itemNo"> <Generator // ID> <!-Свойства отображения-> <name = "itemname"/> <name = "Количество"/> </class> </hibernate mapping>
Тестовый класс:
Бухгалтер 1 загружает данные через пессимистическую блокировку и изменяет данные!
public void testload1 () {Session Session = null; try {session = hibernateutils.getSession (); session.beginTransaction (); /*Пессимистическая блокировка добавляется при загрузке, что делает невозможным для других пользователей получить доступ*/ inventory inv = (инвентарь) Session.load (Inventory.class, "1001", LockMode.upgrade); /*Получить данные*/ system.out.println ("opt1-> itemno =" + inv.getitemno ()); System.out.println ("opt1-> itemname =" + inv.getItemname ()); System.out.println ("opt1-> outity =" + inv.getquantity ()); /*Количество минус 200*/ inv.setquantity (vv.getquantity () - 200); session.getTransaction (). Commit (); } catch (Exception e) {e.printstackTrace (); session.getTransaction (). Rollback (); } наконец {hibernateutils.closesession (Session); }}Бухгалтер 2 и бухгалтер 1 имеют одинаковые операции, и оба изменяют данные в базе данных!
public void testload2 () {session session = null; try {session = hibernateutils.getSession (); session.beginTransaction (); /*Добавить блокировку при загрузке данных, чтобы другие не могли получить Data*/ Inventory Inv = (Inventory) Session.load (Inventory.Class, "1001", LockMode.upgrade); /*Получить реальные данные*/ system.out.println ("opt2-> itemno =" + inv.getitemno ()); System.out.println ("opt2-> itemname =" + inv.getItemname ()); System.out.println ("opt2-> outity =" + inv.getQuantity ()); /*Инвентаризация минус 200*/ inv.setquantity (vv.getquantity () - 200); session.getTransaction (). Commit (); } catch (Exception e) {e.printstackTrace (); session.getTransaction (). Rollback (); } наконец {hibernateutils.closesession (Session); }}Примечание. Операции, выполняемые двумя бухгалтерами, одинаковы. Если добавляется пессимистическая блокировка, бухгалтер берет данные и изменяет данные. Перед тем, как бухгалтер 1 представляет эту вещь, бухгалтер 2 не может получить доступ к данным и может быть только в состоянии ожидания. Только узнав, что бухгалтер 1 представил эту вещь, бухгалтер 2 имеет возможность работать в данных в базе данных.
Благодаря вышеупомянутому пессимистическому шкафу блокировки мы можем обнаружить, что самое большое преимущество пессимистического блокировки заключается в том, что он может предотвратить потерю обновления. Когда калькулятор 1 обрабатывает данные, калькулятор 2 может находиться только в состоянии ожидания. Только после того, как калькулятор 1 представляет эту вещь, калькулятор 2 имеет возможность изменить данные. Но есть также большая проблема, то есть, если бухгалтер 1 запрашивает данные и уезжание, то другим придется ждать большую часть дня, что является очень пустой тратой времени. Чтобы решить эту проблему, мы можем использовать оптимистичные замки.
Оптимистичные замки не являются замками в истинном смысле. В большинстве случаев они реализованы в форме версии данных. Как правило, поле версии добавляется в базу данных, а версия читается при чтении данных. При сохранении данных он определяет, меньше ли значение версии, чем значение версии базы данных. Если это меньше, это не будет обновлено, в противном случае он будет обновлен.
Настройки Javabean под оптимистичными замками, Inventory.java:
Инвентаризация открытого класса { /*Номер инвентаризации* / private String itemno; /*Имя инвентаризации*/ private String ItemName; /*Количество инвентаризации*/ частное количество интенсивного количества; /*Версия данных*/ private int версия; // Опустить методы установки и получения}Inventory.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.bean.inventory" table = "t_inventory" Optimistry-lock = "version"> <!-Первичное картирование ключей-> <id name = "itemno"> <generator/> </id> <!-версия данных, должна быть в месте после первичного ключа-> <версия = "/> <! name = "Количество"/> </class> </hibernate-mapping>
ПРИМЕЧАНИЕ. Файл отображения с использованием оптимистичных замков предусматривает, что отображение поля версии должно быть сопоставлено сначала после первичного идентификатора ключа.
Бухгалтер 1 обрабатывает данные в ситуации оптимистичной блокировки:
public void testload1 () {Session Session = null; try {session = hibernateutils.getSession (); session.beginTransaction (); /*Загрузить данные в оптимистичную блокировку*/ inventory inv = (инвентарь) Session.load (Inventory.Class, "1001"); /*Реальное получение данных*/ 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-> outity =" + inv.getquantity ()); /*Количество минус 200*/ inv.setquantity (vv.getquantity () - 200); session.getTransaction (). Commit (); } catch (Exception e) {e.printstackTrace (); session.getTransaction (). Rollback (); } наконец {hibernateutils.closesession (Session); }}Бухгалтер 2 обрабатывает данные при оптимистичной блокировке (бухгалтер 2 может обрабатывать данные без их отправки)
public void testload2 () {session session = null; try {session = hibernateutils.getSession (); session.beginTransaction (); /*Загрузить данные в оптимистичную блокировку*/ inventory inv = (инвентарь) Session.load (Inventory.Class, "1001"); /*Реальное получение данных*/ 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-> outity =" + inv.getQuantity ()); /*Количество минус 200*/ inv.setquantity (vv.getquantity () - 200); session.getTransaction (). Commit (); } catch (Exception e) {e.printstackTrace (); session.getTransaction (). Rollback (); } наконец {hibernateutils.closesession (Session); }}ПРИМЕЧАНИЕ. В предпосылке, что бухгалтер берет данные и вычитает число на 200 и не отправляет его, бухгалтер 2 также может управлять данными. Это отличается от пессимистического замка. Когда бухгалтер 2 управляет данными и подчиняет их, версия версии данных в базе данных будет добавлена 1. Затем, когда бухгалтер 1 вернется, чтобы отправить вещь, появится сообщение об ошибке, что данные были обновлены, пожалуйста, перезагрузите его.
Пессимистические замки будут влиять на высокую параллелию, поэтому лучше использовать оптимистичные замки.
Выше приведено все подробное объяснение пессимистического блокировки Hibernate и оптимистичных примеров блокировки в этой статье. Я надеюсь, что это будет полезно для всех. Заинтересованные друзья могут продолжать ссылаться на другие связанные темы на этом сайте. Если есть какие -либо недостатки, пожалуйста, оставьте сообщение, чтобы указать это. Спасибо, друзья, за вашу поддержку на этом сайте!