在一个java函数里更新数据库一条数据后，更新没提交马上查询这条数据，能查到更新后的数据吗？

Posted 2023-05-16

看你在哪查。如果是在同一个连接和事务内，是可以查到的。别人查不到。
比如 inert之后
select，是可以查到的追问

肯定是同一个连接同一个事物，是不是只有我这个连接可以查到更新后的数据？

参考技术A 应该是能的 这个你可以测试下啊 很简单的吧 参考技术B 是可以查到的 查到的是上一次的数据 参考技术C 同一个事务内可以查追问

一个函数里，前面的更新没提交，事务没结束，那应该是在同一个事务里吧？查到的是更新后的数据吗？

列更新后的 Java 对象更新

【中文标题】列更新后的 Java 对象更新

【英文标题】：Java Object Update after Column update

【发布时间】：2016-08-27 13:43:06

【问题描述】：

我有一个关于并发控制的问题。

这是场景。

Java API/线程从数据库中读取实体/行。 另一个线程更新同一行。 现在，如果我想更新从步骤 1 中读取的对象/行，我该怎么做？

【问题讨论】：

嗨，苏曼；你能澄清一下你的问题吗？听起来您很担心Concurrency control，但我不确定您希望在第 3 步发生什么。您是否希望第一个线程能够更新该行，即使它会覆盖第二个线程的更新?这就是所谓的丢失更新问题，是一个经典的并发控制问题。

我已经调整了您问题的一些措辞和格式，使其更具可读性。

【参考方案1】：

您需要设置隔离级别。请在下面找到可能有帮助的示例。 例如，您有 3 个并发进程 A、B 和 C。A 启动事务、写入数据和提交/回滚（取决于结果）。 B 只是执行一个 SELECT 语句来读取数据。 C 读取和更新数据。所有这些过程都在同一张表 T 上工作。

READ UNCOMMITTED - no lock on table. You can read data in the table while writing on it. This means, A writes data (uncommited) and B can read this uncommited data and use it (for any purpose). If A executes a rollback, B still has read the data and used it. This is the fastest but most insecure way to work with data since can lead to data holes in not physically related tables (yes, two tables can be logically but not physically related in real world apps =\).
READ COMMITTED - lock on committed data. You can read the data that was only commited. This means, A writes data and B can't read the data saved by A until A executes a commit. The problem here is that C can update data that was read and used on B and B client won't have the updated data.
REPEATABLE READ - lock on block of sql(which is selected by using select query). This means, B reads the data under some condition i.e. WHERE aField > 10 AND aField < 20, A inserts data where aField value is between 10 and 20, then B reads the data again and get a different result.
SERIALIZABLE - lock on full table(on which Select query is fired). This means, B reads the data and no other transaction can modify the data on the table. This is the most secure but slowest way to work with data. Also, since a simple read operation locks the table, this can lead to heavy problems on production: imagine that T table is an Invoice table, user X wants to know the invoices of the day and user Y wants to create a new invoice, so while X executes the read of the invoices, Y can't add a new invoice (and when it's about money, people get really mad, specially the bosses).

希望这会有所帮助。