关于数据库事务的问题

Posted 2023-04-24

我想问一下,如果一个连接把它设置为不自动提交事务状态,那么当我关闭这个连接时会不会把我之前的语句执行呢?因本人提了好些问题都是白白浪费了积分,所以如有合适答复我会追加悬赏分的.绝不食言.
对了这个问题是在jsp中用的.还有就是我想问下在jsp中对数据库操作时如果当我返回的结果集本身为空时.如果我调用rs.next()应该会引发空指针异常吧.好多东西没有经验多谢你们提出的一些看法,要不然自己还真不会往这方面去考虑

1、如果一个连接把它设置为不自动提交事务状态，只有commit transaction之前的数据库操作提交成功，之后的在关闭连接时，会rollback。
2、返回的结果集本身为空时.如果调用rs.next()会引发空指针异常吧，所以在rs.next()之前，一定要检验结果集是否为空。 参考技术A 对于不自动提交的事务在执行任何DML操作都会引起事务的提交，关闭连接就是一种DML操作。 参考技术B 你白白浪费了积分，可能你的问题问的不太清楚，比如这个问题吧，你是在什么系统下用的呢？是程序，还是网页，是在vb，vc，c++，还是asp，jsp...等等，别人不好直接回答，还有题目也要别人一看就知道的意思 参考技术C 不会的，
没提交的事务数据会存储在临时文件里，
关闭连接后临时数据就无效了。-_-##我的观点。学了好久不敢作保。

关于数据库事务中不同隔离级别的一些说明？

【中文标题】关于数据库事务中不同隔离级别的一些说明？

【英文标题】：Some clarifications on different Isolation level in database transaction?

【发布时间】：2011-11-17 06:58:29

【问题描述】：

以下是Wikipedia's Isolation article写的关于REPEATABLE READS的声明

在此隔离级别中，基于锁的并发控制 DBMS 实现保持读写锁（在选定数据上获取） 直到交易结束。但是，范围锁是不受管理的，所以会出现幻读现象（见下文）。

我的问题是交易分别何时开始和结束。

如果我们以在同一链接上具有 REPEATABLE READS 隔离级别的不可重复读取为例，根据我的理解 trnsaction 1 begin 当第一个查询被触发时，即SELECT * FROM users WHERE id = 1. DBMS 将保持对用户表的锁定，直到并且除非事务结束。 这里 By end 我的意思是当连接回滚或提交时未在SELECT * FROM users WHERE id = 1 完成时提交。到那个时候 事务 2 会等待对吗？

---

问题 2 :- 现在，如果我们考虑下面给出的隔离级别和他们的行为（在同一链接上）

Isolation level     Dirty reads   Non-repeatable   Phantoms
Read Uncommitted    may occur     may occur        may occur
Read Committed      -             may occur        may occur
Repeatable Read     -             may occur        -
Serializable        -             -                -

根据我的理解，最可靠的是可序列化，然后是可重复读取，然后是已提交读，但我仍然看到使用已提交读的应用程序。是不是因为 与已提交读取相比，可序列化和可重复读取的性能较差，因为在可序列化中它将是连续的，以防万一 事务必须等待另一个事务释放锁。 对吗？ 所以要充分利用这三个方面，我们可以使用隔离 级别为 Read Committed 和 SELECT FOR UPDATE（实现可重复读取）。如果我们想要，不确定如何实现幻读，以防读取已提交 隔离级别？

【问题讨论】：

查看***.com/questions/10935850/… 了解SELECT ... FOR UPDATE的讨论

因此，为了充分利用这三个方面，我们可以使用隔离级别作为 Read Committed 和 SELECT FOR UPDATE - 这是像 Datanucleus 这样的 JDO 持久层的方法。它们提供了一种机制来在每个事务的基础上控制“SELECT FOR UPDATE”。我相信这种方法在使用“低级”事务类型时会带来 Serializable 事务锁定机制的好处。

您确定在具有“不可重复”隔离级别的事务中可能发生“可重复读取”吗？在这篇文章中，表是不同的 - oracle.com/technetwork/issue-archive/2010/10-jan/…

【参考方案1】：

Oracle 不支持REPEATABLE READ 隔离级别。但是，SQL Server 会这样做——并且它会在事务选择的所有行上加锁，直到它结束（即：它被提交或回滚）。所以你是对的，这确实会让其他事务等待（如果它们正在更新锁定的数据）并且可能不利于并发。

至于问题2：是的，隔离级别越高，你的并发事务执行得越差，因为它们必须等待更多的锁被释放。我不确定您所说的使用 SELECT FOR UPDATE 的“三者合一”是什么意思，因为 SELECT FOR UPDATE 会在所有选定的行上放置行锁。

最后，这里引用了 Oracle 的幻读手册：

[幻读发生在]事务重新运行返回一组满足搜索条件的行的查询，并发现另一个已提交的事务插入了满足条件的其他行。

例如，事务查询员工人数。五分钟后，它执行了相同的查询，但现在这个数字增加了一个，因为另一个用户插入了一条新员工的记录。比以前更多的数据满足查询条件，但与模糊读取不同的是，之前读取的数据没有变化。

---

参考：

Data Concurrency and Consistency（甲骨文） SET TRANSACTION LEVEL（SQL 服务器）

【讨论】：

" 我不确定你所说的“三者中最好的”是什么意思 基本上我在这里要问的是，如果我们在 oracle 中使用读提交隔离级别，我们仍然会得到非可重复和幻读问题。对吧？根据我的理解，首先我们不应该将它们称为问题，但这些应该被视为正确的行为，因为在第一个事务之间，如果第二个事务提交，那么我们应该得到更新的数据。对吧？继续。 ..

继续... 第二个问题是，如果我们想避免在 oracle 上提交的读取出现不可重复和幻读问题，有什么办法吗？根据我的说法，如果我们使用 select 进行更新查询，我们可以从不可重复读取中保存。Coorect？但不确定如何避免幻读？