LockMode.NONE :有缓存用缓存,没缓存则从数据库读
LockMode.READ :直接从数据库读,不使用缓存数据
LockMode.WRITE :在insert update数据的时候,HIBERNATE内部使用的。
以上3种均为HIBERNATE级别的锁,也就是缓存级别的锁。
下面2种为数据库级别的锁:
LockMode.UPGRADE:相当于SQL语句select for update,被select的数据都被数据库锁住了,不能被其他事务修改。
LockMode. UPGRADE_NOWAIT :是ORACLE数据库特有的select for update nowait
NONE
public static final LockMode NONE
No lock required. If an object is requested with this lock mode, a READ lock will be obtained if it is necessary to actually read the state from the database, rather than pull it from a cache.
This is the "default" lock mode.
READ
public static final LockMode READ
A shared lock. Objects in this lock mode were read from the database in the current transaction, rather than being pulled from a cache.
UPGRADE
public static final LockMode UPGRADE
Deprecated. instead use PESSIMISTIC_WRITE
An upgrade lock. Objects loaded in this lock mode are materialized using an SQL select ... for update.
UPGRADE_NOWAIT
public static final LockMode UPGRADE_NOWAIT
Attempt to obtain an upgrade lock, using an Oracle-style select for update nowait. The semantics of this lock mode, once obtained, are the same as UPGRADE.
WRITE
public static final LockMode WRITE
A WRITE lock is obtained when an object is updated or inserted. This lock mode is for internal use only and is not a valid mode for load() or lock() (both of which throw exceptions if WRITE is specified).
FORCE
public static final LockMode FORCE
Deprecated. instead use PESSIMISTIC_FORCE_INCREMENT
Similiar to UPGRADE
except that, for versioned entities, it results in a forced version increment.
OPTIMISTIC
public static final LockMode OPTIMISTIC
Optimisticly assume that transaction will not experience contention for entities. The entity version will be verified near the transaction end.
OPTIMISTIC_FORCE_INCREMENT
public static final LockMode OPTIMISTIC_FORCE_INCREMENT
Optimisticly assume that transaction will not experience contention for entities. The entity version will be verified and incremented near the transaction end.
PESSIMISTIC_READ
public static final LockMode PESSIMISTIC_READ
Implemented as PESSIMISTIC_WRITE. TODO: introduce separate support for PESSIMISTIC_READ
PESSIMISTIC_WRITE
public static final LockMode PESSIMISTIC_WRITE
Transaction will obtain a database lock immediately. TODO: add PESSIMISTIC_WRITE_NOWAIT
PESSIMISTIC_FORCE_INCREMENT
public static final LockMode PESSIMISTIC_FORCE_INCREMENT
Transaction will immediately increment the entity version.
分享到:
相关推荐
主要介绍了Hibernate悲观锁和乐观锁实例详解,分享了相关代码示例,小编觉得还是挺不错的,具有一定借鉴价值,需要的朋友可以参考下
内含hibernate3.2与修复java.lang.NoSuchMethodError: org.objectweb.asm.ClassWriter.(Z)V 的错误的cglib2.2
通过监控数据库实例的锁使用情况,活跃锁的个数、死锁等信息,调整锁个数...1) onstat -k 监控当前活跃锁的个数,参照此设置LOCKS、DEF_TABLE_LOCKMODE参数,避免锁粒度太大、锁个数太多,浪费内存资源,从而影响性能。
当某个数据库用户在数据库中插入、更新、删除一个表的数据,或者增加一个表的主键时或者表的索引时,常常会出现ora-00054:resource busy and acquire with nowait specified这样的错误。 主要是因为有事务正在执行...
3.hibernate的配置文件(hibernate.cfg.xml)得存在 4.POJO.hbm.xml文件存在 5.hibernate的jar包以及数据库的驱动包存在 Hibernate的编程: 1.构建Configuration对象读取配置文件 2.读取映射文件 3.构建SessionFactory...
本文为大家分享了Android九宫格手势解锁的具体代码,供... LockMode lockMode = (LockMode) getIntent().getSerializableExtra(Config.INTENT_SECONDACTIVITY_KEY); //是否显示手势的方向箭头 lv_lock.setShow(false)
sqlalchemy 对于行级锁有两种实现方式,with_lockmode(self, mode): 和 with_for_update(self, read=False, nowait=False, of=None),前者在sqlalchemy 0.9.0 被废弃,用后者代替。所以我们使用with_for_update ! 看...
通过v$lock很容易鉴定出来:可以看到,LockMode为6.等待队列分析当发现系统中由于此类锁导致的等待而致使会话hung住时,可以通过以下过程来找到导致阻塞的会话、语句和对象。续上,在Session2中执行