你需要一个数据库事务来读取数据吗? [英] Do you need a database transaction for reading data?

查看:24
本文介绍了你需要一个数据库事务来读取数据吗?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

当我尝试从数据库中读取数据时,至少使用

When I try to read data from the database, at least using

((Session)em.getDelegate()).createCriteria()

抛出异常表示事务不存在.

an exception is throws saying that a transaction is not present.

当我添加注释时:

@Transactional(
    value = SomeClass.TRANSACTIONAL_MANAGER, 
    propagation = Propagation.SUPPORTS, 
    readOnly = true
)

效果很好.

然而,由于读取每秒会发生数百万次以访问和读取数据,我想确保我们的环境不会被不必要地堵塞.

However, since reading will happen million of times per second to access and read data, I want to make sure that our environment is not clogged up unnecessarily.

如果没有,创建只读Propagation.Supports 交易的成本是多少?

If not, what is the cost of creating a read-only Propagation.Supports transaction?

我可以不创建一个没有事务的 Hibernate Criteria Query 结合 Spring 吗?

Can I not create a Hibernate Criteria Query without a transaction, in combination with Spring?

推荐答案

所有数据库语句都在物理事务的上下文中执行,即使我们没有明确声明事务边界 (BEGIN/COMMIT/ROLLBACK).

All database statements are executed within the context of a physical transaction, even when we don’t explicitly declare transaction boundaries (BEGIN/COMMIT/ROLLBACK).

如果不声明事务边界,那么每个语句都必须在单独的事务中执行(autocommit 模式).这甚至可能导致每个语句打开和关闭一个连接,除非您的环境可以处理每个线程的连接绑定.

If you don't declare transaction boundaries, then each statement will have to be executed in a separate transaction (autocommit mode). This may even lead to opening and closing one connection per statement unless your environment can deal with connection-per-thread binding.

将服务声明为 @Transactional 将在整个事务期间为您提供一个连接,并且所有语句都将使用该单个隔离连接.这比一开始不使用显式事务要好得多.

Declaring a service as @Transactional will give you one connection for the whole transaction duration, and all statements will use that single isolation connection. This is way better than not using explicit transactions in the first place.

在大型应用上,你可能有很多并发请求,降低数据库连接获取请求率肯定会提高你的整体应用性能.

On large applications, you may have many concurrent requests, and reducing database connection acquisition request rate will definitely improve your overall application performance.

JPA 不对读取操作强制执行事务.只有写入才会抛出 TransactionRequiredException 以防您忘记启动事务上下文.尽管如此,即使对于只读事务,声明事务边界总是更好(在 Spring @Transactional 中允许您标记只读事务,这具有很大的性能优势).

JPA doesn't enforce transactions on read operations. Only writes end up throwing a TransactionRequiredException in case you forget to start a transactional context. Nevertheless, it's always better to declare transaction boundaries even for read-only transactions (in Spring @Transactional allows you to mark read-only transactions, which has a great performance benefit).

现在,如果您使用声明式事务边界(例如@Transactional),您需要确保数据库连接的获取被延迟,直到有要执行的 JDBC 语句.在 JTA 中,这是默认行为.使用 RESOURCE_LOCAL 时,需要设置 hibernate.connection.provider_disables_autocommit 配置属性,并确保底层连接池设置为禁用自动提交模式.

Now, if you use declarative transaction boundaries (e.g. @Transactional), you need to make sure that the database connection acquisition is delayed until there is a JDBC statement to be executed. In JTA, this is the default behavior. When using RESOURCE_LOCAL, you need to set the hibernate.connection.provider_disables_autocommit configuration property and make sure that the underlying connection pool is set to disable the auto-commit mode.

这篇关于你需要一个数据库事务来读取数据吗?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆