问题标签 [transaction-isolation]

我的案例场景将参数传递给一个过程，该过程只进行插入。但是两个线程可能会尝试传递相同的值。

如何处理这种情况而不会抛出异常并使用最少的锁？

我的性能要求是每秒至少 10k 次插入。

编辑：列是唯一的。时间戳可能会在插入之前更改（调整）。

好吧，我得到了一个任务 [迷你项目]，其中最重要的问题之一是数据库一致性。该项目是一个 Web 应用程序，允许多个用户访问和使用它。我可以期待并发查询和更新请求到一小组表中，其中一些表相互连接（使用外键）。

为了保持数据库尽可能一致，我们被建议使用隔离级别。在阅读了一些（可能还不够？）关于它们的信息后，我认为对我来说最有用的是 READ COMMITTED 和 SERIALIZABLE。

我可以将查询分为三种：

1. 获取查询
2. 更新查询
3. 组合

对于第一个，我当然需要数据是一致的，我不想呈现脏数据，或者未提交的数据等。因此，我想对这些查询使用 READ COMMITTED。对于更新查询，我认为使用 SERIALIZABLE 将是最好的选择，但是在阅读了一下之后，我发现自己迷路了。在组合中，我可能不得不从数据库中读取数据，并决定我是否需要/可以更新，这 2-3 个调用将在同一个事务下。

想征求一些建议，在这些查询选项中使用哪种隔离级别。我是否应该为每种类型考虑不同的隔离级别？还是坚持一个？

我正在使用 MySQL 5.1.53，以及 MySQL JDBC 3.1.14 驱动程序（要求...没有选择 JDBC 版本）

非常感谢您的见解！

编辑：

我决定我将使用REPEATABLE READ，这似乎是默认级别。我不确定这是否是正确的方法，但我想REPEATABLE READ以及LOCK IN SHARE MODE和FOR UPDATE查询应该可以正常工作......

你们有什么感想？

Serializable Isolation Level的 PostgreSQL 手册页指出：

[像] 可重复读取级别，使用此级别的应用程序必须准备好由于序列化失败而重试事务。

在可重复读取或可序列化级别遇到序列化失败的条件是什么？

我试图通过两个运行实例来引发序列化失败psql，但即使一个事务由一个实例提交，另一个实例在可序列化级别事务中，而另一个实例已成功提交其更改。两者都只是将记录插入到表中，所以也许我需要尝试更复杂的东西。

基本上我试图了解在序列化失败的情况下会发生什么以及序列化失败是如何出现的。

我有一个任务线程在两个单独的 tomcat 实例中运行。任务线程在某些 where 条件下同时读取（使用选择）TASKS 表，然后进行一些处理。

问题是，有时两个线程都会选择相同的任务，因此该任务会执行两次。我的问题是如何让两个线程不从 TASKS 表中读取同一组数据

使用 SQL Server 的事务隔离级别，您可以避免某些不需要的并发问题，例如脏读等。

我现在感兴趣的是丢失更新——事实上两个事务可以在没有人注意到的情况下覆盖彼此的更新。我看到并听到关于我必须选择至少哪个隔离级别来避免这种情况的相互矛盾的陈述。

Kalen Delaney 在她的“SQL Server Internals”一书中说（第 10 章 - 事务和并发 - 第 592 页）：

在 Read Uncommitted 隔离中，前面描述的所有行为，除了丢失更新之外，都是可能的。

另一方面，给我们上课的独立 SQL Server 培训师告诉我们，我们至少需要“可重复读取”以避免丢失更新。

那么谁是对的？？为什么？

我有一个类似这样的代码：

这不起作用，我已经测试了查询，并且在提交数据时它们可以有效地工作，但是当它没有提交时，它会出现不允许我检查脏读的问题，即使隔离级别设置为 readuncommitted 也是如此。我想弄清楚为什么我不能访问这些信息，因为我不能以任何方式将信息提交到我们的数据库，因为这是一种测试方法。
谢谢你！

这是整个事情

......

根据这篇文章，可序列化的隔离级别对行执行读锁和范围锁。因此，如果在一个事务中我SELECT对某些行（或行）执行语句，则尝试查询相同行（或该行的子集）的另一个事务将锁定，直到第一个事务提交或回滚。正确的？但是在 oracle 中我尝试执行这样的场景并且第二个事务没有被锁定。为什么在我在第一个事务中执行提交之前它不会锁定？

我听说许多应用程序开发人员在数据库处理中的竞争条件方面遇到了一些麻烦。一个典型的例子是这样的：

• 用户 1 选择一个字段，例如 numStock，它是 3
• 用户 2 也选择了 numStock，仍然是 3
• 用户 1 递减 numStock（在应用程序中），并在数据库中将其设置为 2。
• 用户 2 还递减 numStock（在应用程序中），并在数据库中将其设置为 2。

在此示例中，numStock 字段应该已变为 1，但由于用户之间的竞争，它被设置为 2。

所以当然可以使用锁，但我想到了另一种处理方式 - 将所有行详细信息作为 WHERE 标准传递。让我解释...

在上面的示例中，SQL 代码可能如下所示：

//选择

//更新

我解决比赛的想法：

//选择

//更新

因此，查询检查数据是否在选择数据后发生了变化。所以我的问题是：（1）这[总是]有效吗？(2) 与数据库锁定机制（例如，MySQL 事务）相比，这是一个更好的选择吗？

谢谢你的时间。

我的 Java 应用程序需要以原子和隔离的方式执行一组 DB 语句。例如，应用程序需要从一个表中读取数据行并更新另一个表中的数据行。

事务管理是通过将连接的自动提交设置为 false 并稍后显式提交来实现的，如上所示。但是上面的代码也可以在多线程环境中执行，我还希望两个数据库语句（选择和更新）作为一个整体相互独占运行。

我有一些想法在该方法中使用共享的 Java Lock 对象，如下所示。

在课堂里，

在方法中，

它似乎有能力解决这个问题。但是，我想知道这是否是最佳实践，是否有更好的替代方案（例如框架）？

If two transactions (both at RR isolation level) ask for the same item which is 2nd-level cached, and then they modify and store this item. Now, for reading that item, they did not run any SQL because it's cached; so in this case, will they actually start a data base transaction? And when they commit their changes, will they run into lost update problem?