企业网站建设方讯,中企动力300官网,网站关闭模板,国内做网站多少钱返回#xff1a;SQLite—系列文章目录
上一篇#xff1a;SQLite版本3中的文件锁定和并发(七#xff09;
下一篇#xff1a;SQLite—系列文章目录 数据库的“isolation”属性确定何时对 一个操作的数据库对其他并发操作可见。
数据库连接之间的隔离
如果使用两个不… 返回SQLite—系列文章目录
上一篇SQLite版本3中的文件锁定和并发(七
下一篇SQLite—系列文章目录 数据库的“isolation”属性确定何时对 一个操作的数据库对其他并发操作可见。
数据库连接之间的隔离
如果使用两个不同的数据库连接读取和写入同一个数据库两个不同的 sqlite3 对象返回 单独调用 sqlite3_open 和两个数据库连接 没有共享缓存则读取器只能 请参阅编写器的完整已提交事务。部分更改 作者没有承诺的对读者来说是不可见的。 无论两个数据库连接是否在 同一线程在同一进程的不同线程中或在 不同的过程。这 是 SQL 数据库系统的常见行为和预期行为。
上一段也是正确的单独的数据库连接是 彼此隔离在共享缓存模式下只要read_uncommitted编译指示保持关闭状态即可。默认情况下read_uncommitted编译指示处于关闭状态因此如果应用程序不执行任何操作来打开它 它将保持关闭状态。因此除非使用read_uncommitted编译指示 若要更改默认行为请由一个数据库连接所做的更改 对于共享 相同的缓存直到写入器提交其事务。
如果两个数据库连接共享同一个缓存并且读取器具有 启用了read_uncommitted编译指示然后读者将能够 请参阅编写器在编写器事务提交之前所做的更改。 共享缓存模式和read_uncommitted指示的组合使用是一个数据库连接可以查看未提交的更改的唯一方法 在不同的数据库连接上。在所有其他情况下分开 数据库连接彼此完全隔离。
除了打开PRAGMA read_uncommitted共享缓存数据库连接的情况外SQLite中的所有事务都显示 “可序列化”隔离。SQLite 实现可序列化事务 通过实际序列化写入。只能有一个作家 一次到一个 SQLite 数据库。可以有多个数据库连接 同时打开所有这些数据库连接都可以写入 到数据库文件但他们必须轮流。SQLite使用锁 自动序列化写入;这不是什么 使用SQLite的应用程序需要担心。
隔离和并发
SQLite 使用 与数据库文件位于同一目录中的暂时性日志文件。 有两种主要的“日志模式”。 较旧的“回滚模式”对应于使用“DELETE”、“PERSIST”、 或“TRUNCATE”选项添加到journal_mode编译指示中。在回滚模式下 更改将直接写入数据库文件同时 构造一个单独的回滚日志文件该文件能够恢复 如果事务回滚则数据库恢复到其原始状态。 回滚模式特别是 DELETE 模式即回滚日志 在每次事务结束时从磁盘中删除是当前 默认行为。
从3.7.0版2010-07-21开始 SQLite还支持“WAL模式”。在 WAL 模式下 更改不会写入原始数据库文件。相反更改 进入单独的“预写日志”或“WAL”文件。 后来交易后 提交时这些更改将从 WAL 文件移回 原始数据库在名为“checkpoint”的操作中。WAL 模式是 通过运行“PRAGMA journal_modeWAL”启用。
在回滚模式下SQLite通过锁定数据库来实现隔离 文件并防止其他数据库连接读取 而每个写入事务都在进行中。 读者可以在写作开始时在任何内容之前处于活动状态 刷新到磁盘而所有更改仍保存在编写器的 专用内存空间。但在对数据库文件进行任何更改之前 在磁盘上必须暂时驱逐所有读取器才能给写入器 对数据库文件的独占访问。 因此禁止读者看到不完整的内容 由于被锁定在数据库之外的事务而 事务正在写入磁盘。只有在交易之后 完全写入并同步到磁盘并提交是允许的读取器 返回到数据库中。因此读者永远没有机会看到部分内容 书面更改。
WAL 模式允许同时读取和写入。它可以这样做因为 更改不会覆盖原始数据库文件而是执行 添加到单独的预写日志文件中。这意味着读者可以继续 从原始数据库文件中读取旧的、原始的、未更改的内容 同时编写器将追加到预写日志中。 在WAL模式下SQLite表现出“快照隔离”。当读取事务时 开始该读者继续看到数据库的不变“快照” 文件因为它在读取事务开始时存在。 在读取事务 active 对读取事务仍然不可见因为读取器是 查看前一时刻的数据库文件快照。
举个例子假设有两个数据库连接 X 和 Y。 使用 BEGIN 后跟一个或多个 SELECT 语句的读取事务。 然后 Y 出现并运行 UPDATE 语句来修改数据库。 X 随后可以对 Y 修改的记录执行 SELECT但 X 将看到较旧的未修改条目因为 Y 的更改都是 当 X 持有读取事务时X 不可见。如果 X 想看 Y 所做的更改则 X 必须结束其读取事务并且 启动一个新的通过运行 COMMIT然后运行另一个 BEGIN。
另一个示例X 使用 BEGIN 和 SELECT 启动读取事务然后 Y 使用 UPDATE 对数据库进行更改。然后 X 尝试做一个 使用 UPDATE 更改为数据库。X 试图升级其 从读取事务到写入事务的事务失败并显示SQLITE_BUSY_SNAPSHOT错误因为数据库的快照正在 查看的 X 不再是数据库的最新版本。如果 X 是 允许写入它将分叉数据库文件的历史记录即 SQLite不支持的东西。为了让 X 写入数据库 它必须首先发布其快照例如使用 ROLLBACK然后 使用后续 BEGIN 启动新事务。
如果 X 启动一个事务该事务最初只会读取但 X 知道它 最终会想写不想被烦恼 由于另一个连接而可能出现的SQLITE_BUSY_SNAPSHOT错误 在队列中跳到它前面然后 X 可以发出 BEGIN IMMEDIATELY 来启动 它的交易而不仅仅是普通的 BEGIN。BEGIN IMMEDIATE 命令继续并启动写入事务从而阻止所有 其他作家。如果 BEGIN IMMEDIATE 操作成功则没有 该事务中的后续操作将失败并出现SQLITE_BUSY错误。
同一数据库连接上的操作之间没有隔离
SQLite 在单独的数据库中提供操作之间的隔离 连接。但是操作之间没有隔离 发生在同一数据库连接中。
换言之如果 X 使用 BEGIN IMMEDIATE 开始写入事务然后发出一个或多个 UPDATE、DELETE 和/或 INSERT 语句则这些更改对后续 SELECT 语句可见 在数据库连接 X 中计算的。 不同的数据库连接 Y 将不显示任何更改直到 X 事务提交。但是 X 中的 SELECT 语句将显示更改 在提交之前。
在单个数据库连接 X 中SELECT 语句始终看到所有 在 SELECT 开始之前完成的对数据库的更改 语句无论是已提交的还是未提交的。和 SELECT 语句 显然看不到 SELECT 语句之后发生的任何更改 完成。但是在 SELECT 语句中发生的更改呢 正在跑步吗如果启动了 SELECT 语句并且 sqlite3_step 接口单步执行了大约一半的输出则某些 UPDATE 语句由修改表的应用程序运行该 SELECT 语句正在读取然后对 sqlite3_step 进行更多调用 完成 SELECT 语句将 SELECT 的后续步骤 声明是否看到 UPDATE 所做的更改答案是 此行为未定义。特别是无论 SELECT 语句是否 看到并发更改取决于 SQLite 的哪个版本 running数据库文件的架构无论 ANALYZE 是否具有 已运行以及查询的详细信息。在某些情况下这可能取决于 在数据库文件的内容上也是如此。没有好的方法可以知道是否 或者 SELECT 语句不会看到对数据库所做的更改 通过启动 SELECT 语句后的同一数据库连接。 因此开发人员应该努力避免编写应用程序 对在这种情况下会发生什么做出假设。
如果应用程序在单个表上发出 SELECT 语句例如 “SELECT rowid * FROM table WHERE ...” 并开始单步执行 使用 sqlite3_step 的该语句的输出并检查每个 行则应用程序可以安全地删除当前行或 使用“DELETE FROM table WHERE rowid”的任何前行。它也是安全的 从某种意义上说它不会损害数据库让应用程序 删除预计稍后在查询中出现但尚未出现的行 出现了。但是如果删除了将来的行则可能会发生以下情况 该行在随后的 sqlite3_step 之后出现即使在它有 据称已被删除。或者它可能不是。该行为是未定义的。 应用程序可以 此外当 SELECT 语句 正在运行但是否显示新行 在查询的后续 sqlite3_step 中未定义。和应用程序 可以更新当前行或任何前一行但这样做可能会导致 该行将在随后的 sqlite3_step 中重新出现。只要 应用程序准备处理这些歧义操作 它们本身是安全的不会损害数据库文件。
就前两段而言两个数据库连接 具有相同共享缓存且已启用 PRAGMA read_uncommitted的数据库连接被视为相同的数据库连接。
总结 SQLite 中的事务是可序列化的。 在一个数据库连接中所做的更改对所有其他数据库都是不可见的 提交前的连接。 查询将查看在同一数据库连接上完成的所有更改 在查询开始之前无论这些更改是否发生 已经提交。 如果查询后同一数据库连接发生更改 开始运行但在查询完成之前则不确定是否 或者查询不会看到这些更改。 如果查询后同一数据库连接发生更改 开始运行但在查询完成之前查询可能会返回 多次更改的行或者它可能会返回以前更改的行 删除。 就前四项而言两个数据库连接 使用相同的共享缓存并且启用 PRAGMA read_uncommitted 被视为相同的数据库连接而不是单独的数据库 连接。
