zoukankan      html  css  js  c++  java
  • Pessimistic and optimistic locking

    Transactional isolation is usually implemented by locking whatever is accessed in a transaction. There are two different approaches to transactional locking: Pessimistic locking and optimistic locking.

    The disadvantage of pessimistic locking is that a resource is locked from the time it is first accessed in a transaction until the transaction is finished, making it inaccessible to other transactions during that time. If most transactions simply look at the resource and never change it, an exclusive lock may be overkill as it may cause lock contention, and optimistic locking may be a better approach. With pessimistic locking, locks are applied in a fail-safe way. In the banking application example, an account is locked as soon as it is accessed in a transaction. Attempts to use the account in other transactions while it is locked will either result in the other process being delayed until the account lock is released, or that the process transaction will be rolled back. The lock exists until the transaction has either been committed or rolled back.

    With optimistic locking, a resource is not actually locked when it is first is accessed by a transaction. Instead, the state of the resource at the time when it would have been locked with the pessimistic locking approach is saved. Other transactions are able to concurrently access to the resource and the possibility of conflicting changes is possible. At commit time, when the resource is about to be updated in persistent storage, the state of the resource is read from storage again and compared to the state that was saved when the resource was first accessed in the transaction. If the two states differ, a conflicting update was made, and the transaction will be rolled back.

    In the banking application example, the amount of an account is saved when the account is first accessed in a transaction. If the transaction changes the account amount, the amount is read from the store again just before the amount is about to be updated. If the amount has changed since the transaction began, the transaction will fail itself, otherwise the new amount is written to persistent storage.

    from: https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/TransactionJTA_Overview-Pessimistic_and_optimistic_locking.html

  • 相关阅读:
    windows笔记进程的句柄
    windows笔记创建线程的函数CreateThread
    c#实现从其他网站抓取imei码信息,手工输入验证码
    Linux下自动修改用户密码的方法(直接通过命令而不是在终端输入密码)
    Redis学习笔记List数据类型
    在Linux(centos)上安装PHP的mongodb扩展
    CI(codeigniter)如何防止sql注入
    MongoDB增加用户认证: 增加用户、删除用户、修改用户密码、读写权限、只读权限
    Sublime Text编辑器如何显示顶部的菜单栏
    C#图片选择器
  • 原文地址:https://www.cnblogs.com/xzs603/p/7053821.html
Copyright © 2011-2022 走看看