MonetDB table level write lock? OR it's repeatable read above isolate?

简介:
在测试对单个表执行insert时, 发现并行的话会导致除最早提交的事务以外的其他事务回滚.

来看个例子 :
sql>\d d
CREATE TABLE "sys"."d" (
        "id"   INTEGER,
        "info" VARCHAR(64),
        "c1"   VARCHAR(64)
);


当前d表有1条记录.
sql>select * from d;
+------+------+------+
| id   | info | c1   |
+======+======+======+
|    1 | test | test |
+------+------+------+
1 tuple (1.698ms)

开启会话1, 插入一条记录, 可以查看到有2条记录
sql>start transaction;
auto commit mode: off
sql>insert into d values (2,'test','test');
1 affected rows (0.726ms)
sql>select * from d;
+------+------+------+
| id   | info | c1   |
+======+======+======+
|    1 | test | test |
|    2 | test | test |
+------+------+------+
2 tuples (1.595ms)


开启会话2, 查看只有1条记录, 说明至少是read committed隔离级别.
sql>start transaction;
auto commit mode: off
sql>select * from d;
+------+------+------+
| id   | info | c1   |
+======+======+======+
|    1 | test | test |
+------+------+------+
1 tuple (1.299ms)

在会话2删除这条记录. 再次查看没有记录了
sql>delete from d;
1 affected rows (0.684ms)
sql>select * from d;
+----+------+----+
| id | info | c1 |
+====+======+====+
+----+------+----+
0 tuples (1.152ms)


在会话1, 还可以看到2条记录
sql>select * from d;
+------+------+------+
| id   | info | c1   |
+======+======+======+
|    1 | test | test |
|    2 | test | test |
+------+------+------+
2 tuples (0.926ms)

会话2提交, 成功
sql>commit;
auto commit mode: on


在会话1, 还可以看到2条记录, 现在有点像repeatable read或者ssi隔离级别了.
sql>select * from d;
+------+------+------+
| id   | info | c1   |
+======+======+======+
|    1 | test | test |
|    2 | test | test |
+------+------+------+
2 tuples (1.065ms)

提交会话1失败
sql>commit;
COMMIT: failed

在会话1再次查看表d, 已经没有记录了. 因为会话2删除了d的所有记录
sql>select * from d;
+----+------+----+
| id | info | c1 |
+====+======+====+
+----+------+----+
0 tuples (1.399ms)


从现象上看, 在事务过程中并没有锁冲突发生, 在事务提交的时候检测到冲突后回滚. 
所以先提交的事务成功了, 后提交的事务就失败了.
这样也没有死锁的问题. 反正不会等待.
来看一下MonetDB对事务的介绍 : 用的是OCC并发控制方法, 提交时检测冲突, 所以不适合有增删改冲突的并行长事务场景.

Transactions

MonetDB/SQL supports a multi-statement transaction scheme marked by START TRANSACTION and closed with either COMMIT or ROLLBACK. The session variableauto_commit can be set to true if each SQL statement should be considered an independent transaction.

WARNING. The transaction management scheme is based on optimistic concurrency control. It provides each transaction with a consistent view on the database, but updates are collected in an addendum processed on transaction commit. If at commit time it can be assured that the data prepared for update affects tables has not changed in the mean time, the results are merged. 
This optimistic concurrency scheme is particularly useful for query dominant environments. It negatively affects long running transactions which concurrently are affected by updates on their underlying tables.

WARNING. Optimistic concurrency control may be confusing for those who built online-transaction applications, because the granularity of the concurrency control scheme will show higher then expected transaction failures. There is not a locking schema to avoid this. Applications may have to resort to serial execution.

WARNING. The tuples being deleted are only marked as such. They do not reduce the table size. It calls for a vacuum cleaning algorithm.

为什么说是表级别的冲突呢? 因为不同的表的DML不会冲突.
例如 :
会话1
sql>start transaction;
auto commit mode: off
sql>insert into d values(100,'test','test');
1 affected rows (0.678ms)
会话2
sql>start transaction;
auto commit mode: off
sql>insert into c values(100,'test','test');
1 affected rows (0.678ms)
会话1
sql>commit;
auto commit mode: on
会话2
sql>commit;
auto commit mode: on

都提交成功

[参考]
目录
相关文章
|
JSON 搜索推荐 API
抖音商品详情API接口:获取商品信息的指南
抖音商品详情API接口由抖音开放平台提供,允许第三方应用访问抖音小店的商品数据,包括基本信息、价格、库存及用户评价等。其优势在于数据实时性、自动化处理、市场分析及个性化推荐。通过注册账号、获取API密钥、阅读文档和构建请求,用户可高效获取商品信息,提升运营效率。未来,该接口将在电商领域发挥更大作用。
|
11月前
|
JSON JavaScript 前端开发
开发桌面程序-Electron入门
【10月更文挑战第16天】Electron 是一个使用 JavaScript、HTML 和 CSS 构建跨平台桌面应用的框架,嵌入了 Chromium 和 Node.js。本文介绍了如何搭建 Electron 开发环境,包括安装 Node.js、创建项目、配置 main.js 和打包应用。通过简单的步骤,你可以快速创建并运行一个基本的 Electron 应用程序。
488 4
开发桌面程序-Electron入门
|
12月前
|
人工智能 算法 安全
基于YOLOV8的骑行智能守护实时检测系统【训练和系统源码+Pyside6+数据集+包运行】
基于YOLOv8的骑行智能守护实时检测系统,通过图像处理和AI技术,实时监测电动车及骑行者头盔佩戴情况,提升道路安全。该系统支持图片、视频和摄像头实时检测,具备GUI界面,便于操作和展示结果。使用5448张真实场景图片训练,包含电动车和骑行者是否佩戴头盔的三类标注。系统基于Python和Pyside6开发,具备模型权重导入、检测置信度调节等功能。
533 0
基于YOLOV8的骑行智能守护实时检测系统【训练和系统源码+Pyside6+数据集+包运行】
|
安全 数据挖掘 定位技术
工厂内部导航系统:高精度定位与智能路径规划的技术实现
工厂内部导航系统其核心功能包括实时定位、智能路径规划、车辆警告及数据分析,显著提升了物流效率和管理水平。系统具备高精度定位、灵活部署及跨平台兼容等技术优势,并已在实际项目中取得显著成效。
390 11
工厂内部导航系统:高精度定位与智能路径规划的技术实现
|
人工智能 前端开发 算法
【2023五福】创新科技与传统年俗的有机融合 - AI 年画
23 年兔年,五福项目将传统的写福字升级成了年画,用户通过绘制兔子轮廓可以得到活动的兔子,同时由 AI 生成对应的兔子年画,整个过程给用户带来很强的惊喜感,同时将具有传统氛围的年画与科技感拉满的 AI 作图有机结合,为大家带来全新的年俗体验。AI 年画作为 23 兔年五福的创新项目,在玩法和技术方案上都采用全新的实现,前后端技术、AI 算法深度,以及美术互动等深度协同,实现了玩法了技术的双创新,最
【2023五福】创新科技与传统年俗的有机融合 - AI 年画
|
存储 关系型数据库 MySQL
MySQL InnoDB存储引擎的优点有哪些?
上述提到的特性和优势使得InnoDB引擎非常适合那些要求高可靠性、高性能和事务支持的场景。在使用MySQL进行数据管理时,InnoDB通常是优先考虑的存储引擎选项。
427 0
|
机器学习/深度学习 编解码 人工智能
视频分辨率的历史发展,未来趋势是什么?
随着技术的不断发展,视频分辨率也在不断提高。视频分辨率是指视频图像中可显示的像素数量,通常表示为水平像素数和垂直像素数。它对于观看视频时的清晰程度和细节呈现有着重要的影响。 本文将会介绍视频分辨率的基本概念,包括单位、历史发展、标准和未来趋势。我们还会探讨视频分辨率对观影体验的影响以及如何选择适合自己设备的视频分辨率。 无论您是电影爱好者还是普通用户,通过本文,您将能够了解到视频分辨率在过去的发展历程和未来的趋势,从而更好地使用和享受视频娱乐。
视频分辨率的历史发展,未来趋势是什么?
|
存储 JSON 安全
NFT数字藏品交易系统平台开发核心方案
数字藏品是基于区块链技术(境内联盟链)记账的具有一定收藏价值的数字化商品。数字藏品不同于境外容易形成空气币的代币、虚拟币等,它有真实商品价值背书。
阿里云商标注册申请进度查询攻略来了
阿里云商标注册申请进度查询(太简单了),阿里云商标申请进度查询可以通过手机微信接收商标申请进度信息,在阿里云公众号“阿里云企航”中即可接收商标注册申请进度查询。商标注册申请提交到商标局后需要长达数月的审查过程,实时查询商标注册进度是十分必要的,阿里云百科分享阿里云商标注册申请进度查询方法:
1601 1
阿里云商标注册申请进度查询攻略来了
|
机器学习/深度学习 人工智能 编解码
阿里云PAI-Diffusion功能再升级,全链路支持模型调优,平均推理速度提升75%以上
本⽂首先介绍如何体验PAI-Diffusion模型以及其在线部署、加速推理能力。其次,我们简单回顾了PAI-Diffusion模型的架构,之后详细介绍了在EasyNLP算法框架中对上述模型进行调优的全链路支持。
阿里云PAI-Diffusion功能再升级,全链路支持模型调优,平均推理速度提升75%以上