Java Spring @Transactional 和 Hibernate @LockMode 注释是如何相关的

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/37980677/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-08-11 19:52:16  来源:igfitidea点击:

How are the Spring @Transactional and the Hibernate @LockMode annotations related

javaspringhibernatetransactionslocking

提问by vivek4348

I wish to know the relation between transactions and locks.

我想知道事务和锁之间的关系。

To be more specific, how is Spring's @Transactionalrelated to Hibernate's LockMode. https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html. http://docs.spring.io/autorepo/docs/spring/4.2.x/spring-framework-reference/html/transaction.html

更具体地说,Spring@Transactional与 Hibernate 的 LockMode 有什么关系。https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.htmlhttp://docs.spring.io/autorepo/docs/spring/4.2.x/spring-framework-reference/html/transaction.html

If I dont specify any lock while creating Session Object, and use @Transactionalwith readOnlyas false, am I using Pessimistic Concurrenct Control.

如果在创建Session对象,我不指定任何锁,并使用@TransactionalreadOnly作为false,我使用悲观Concurrenct控制。

It would be a great help, if anyone can tell me the relation between (Optimistic/Pessimistic) Concurrency Control and Transactions.

如果有人能告诉我(乐观/悲观)并发控制和事务之间的关系,那将是一个很大的帮助。

Thank you, Vivek

谢谢你,维维克

采纳答案by Vlad Mihalcea

There is no directrelationship between @Transactionaland @LockModeannotations.

和注解之间没有直接关系。@Transactional@LockMode

As explained in this post, @Transactionalis used to mark the explicit boundaries of a RESOURCE_LOCAL or JTA transaction. The reason why you need it it is because every database statement executes in a transactional context, and, if you don't set the transaction boundaries, you'll get one transaction per statement or auto-commit.

正如在解释这个帖子@Transactional是用来标记RESOURCE_LOCAL或JTA事务的明确界限。您需要它的原因是因为每个数据库语句都在事务上下文中执行,并且,如果您不设置事务边界,则每个语句或自动提交将获得一个事务。

On the other hand, @LockModeTypeis for setting explicit locking options. If you don't set it, the implicit locking mechanisms will be used:

另一方面,@LockModeType用于设置显式锁定选项。如果不设置,将使用隐式锁定机制:

  • Implicit locks are acquired on every modified row on both 2PL and MVCC database engines. Shared locks are acquired on read records on 2PL engines if you use Repeatable Read on Serializable.
  • If you defined a @Versionproperty, the implicitoptimistic locking mechanism will be used.
  • 在 2PL 和 MVCC 数据库引擎上的每个修改行上都获取隐式锁。如果在 Serializable 上使用可重复读取,则会在 2PL 引擎上的读取记录上获取共享锁。
  • 如果定义了@Version属性,将使用隐式乐观锁定机制

So, @LockModeTypeis for setting locking options explicitly, and you can have the following options:

因此,@LockModeType用于显式设置锁定选项,您可以有以下选项:

The PESSIMISTIClock modes will always acquire a database lock on the table row that is associated with the locked entity.

PESSIMISTIC锁模式将始终掌握在与该锁定实体相关联的表行数据库锁。

There are also explicit optimistic lock strategies:

还有显式的乐观锁策略:

The OPTIMISTIClock modes are meant to give you a way of bumping up an entity version even if the entity hasn't changed in the currently running Persistence Context. This is a very useful mechanism when you need to coordinate multiple child entities using their parent entity version.

OPTIMISTIC锁模式是为了给你撞了,即使实体并没有在当前运行的持久化上下文变化的实体版本的方式。当您需要使用父实体版本协调多个子实体时,这是一种非常有用的机制。

There are lots of examples in the links that I provided in this answer, so take your time, read them all, and you'll understand all these concepts in greater detail.

我在此答案中提供的链接中有很多示例,因此请花点时间阅读所有示例,您将更详细地了解所有这些概念。

回答by ck1

Spring's @Transactionaland Hibernate's LockModeclass are different.

Spring@Transactional和 Hibernate 的LockMode类是不同的。

Spring Transaction Management

Spring事务管理

@Transactionalis a Spring annotation for declarative transaction management, i.e. defining what SQL statements are executed together inside of a database transaction. Using the readOnlyattribute allows Spring to throw an exception if you attempt to insert rows inside of a read-only transaction, for example.

@Transactional是用于声明式事务管理的 Spring 注释,即定义在数据库事务内一起执行哪些 SQL 语句。readOnly例如,如果您尝试在只读事务中插入行,则使用该属性允许 Spring 抛出异常。

With respect to locking, however, you'll most likely be using a read/write (readOnly = false) transaction, because you'll be attempting to modify data.

但是,关于锁定,您很可能会使用读/写 ( readOnly = false) 事务,因为您将尝试修改数据。

Pessimistic Locking

悲观锁

Hibernate's LockModeis used for pessimistic locking, e.g. LockMode.UPGRADEactually executes a SELECT...FOR UPDATEstatement, and locks the row in the database corresponding to the entity.

Hibernate 的LockMode用于悲观锁定,例如LockMode.UPGRADE实际执行一条SELECT...FOR UPDATE语句,并锁定数据库中实体对应的行。

Pessimistic locking assumes that concurrent transactions will conflict with each other, and requires resources to be locked after they are read and only unlocked after the application has finished using the data.

悲观锁假设并发事务会相互冲突,并要求资源在被读取后锁定,并且只有在应用程序使用完数据后才解锁。

Optimistic Locking

乐观锁定

Optimistic concurrency control in Hibernate typically uses a version or timestamp column in the database. The idea here is that if multiple transactions attempt to modify a row concurrently, all but the first committed transaction will detect that the version number has changed and perform a rollback.

Hibernate 中的乐观并发控制通常使用数据库中的版本或时间戳列。这里的想法是,如果多个事务尝试同时修改一行,除第一个提交的事务之外的所有事务都将检测到版本号已更改并执行回滚。

Optimistic locking assumes that multiple transactions can complete without affecting each other, and that therefore transactions can proceed without locking the data resources that they affect. Before committing, each transaction verifies that no other transaction has modified its data. If the check reveals conflicting modifications, the committing transaction rolls back.

乐观锁定假设多个事务可以完成而不相互影响,因此事务可以在不锁定它们影响的数据资源的情况下继续进行。在提交之前,每个事务都会验证没有其他事务修改了它的数据。如果检查显示有冲突的修改,提交事务将回滚。

Quotes above are from: https://docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html

以上引述来自:https: //docs.jboss.org/hibernate/orm/4.0/devguide/en-US/html/ch05.html