我阅读了不同事务隔离级别的内容,并在SERIALIZABLE隔离级别上进行了讨论。我还知道,Postgres、Oracle和MySQL等数据库支持SELECT .. FOR UPDATE语法。
然而,当我想要锁定希望对其执行更新的行(或一系列行)时,我很困惑应该如何使用这些数据。
在过去使用JPA时,我总是在查询中使用@Transactional和一个LockModeType.PESSIMISTIC_WRITE。这意味着在SQL中使用READ_COMMITTED隔离级别和SELECT .. FOR UPDATE。
但是现在,在阅读了SERIALIZABLE之后,我想知道如果我使用@Transa
我正在编写一些代码,它使用行级锁定和MySQL (innodb后端)。
伪码是:
START TRANSACTION
SELECT * FROM foo WHERE foocondition FOR UPDATE
UPDATE foo set bar=value WHERE foocondition
COMMIT
我在mysql文档中找不到提交后持有的锁的信息。
我是否必须在提交后执行“解锁表”,还是它是隐式的?答案应该是“不”,但我想得到有关的反馈。
我想做一个金融交易,但我不是真正熟悉的MySQL交易功能。
我想确定我做的所有事情都是正确的。我的目标是在我的事务期间“锁定”我的transactionHistory和transactionQueued表,以确保帐户余额是正确的,并且不能插入其他事务操纵余额/同时。
SET autocommit=0;
START TRANSACTION;
IF (
SELECT SUM(amount) of transactionHistory WHERE account = 1
+
SELECT SUM(amount) of transactionsQueued WHERE account = 1)
(使用SpringBoot2.3.3w/ MySQL 8.0)
假设我有一个Account实体,它包含一个total字段,其中一个帐户实体代表某种类型的主帐户。也就是说,主帐户几乎每个事务都更新了它的total字段,而对该total字段的任何更新都是根据最近的值完成的。
在这样的交易中,哪个是更好的选择:
使用PESSIMISTIC_WRITE锁,获取主帐户,增加总字段,并提交事务。或者,
有一个专门的查询,本质上是作为事务的一部分执行UPDATE Account SET total = total + x之类的操作?我假设在这种情况下,更新查询仍然需要相同的悲观锁,例如通过@Lock.和@Q
我已经阅读并测试了MySQL的InnoDB中的行级锁,但我仍然很难说“我知道锁在MySQL中是如何工作的”!
以下是我的测试数据:
mysql> select * from lockable;
+----+----+----+
| id | c1 | c2 |
+----+----+----+
| 1 | A | A |
| 2 | A | B |
| 3 | A | C |
| 4 | B | A |
| 5 | B | B |
| 6 | B | C |
| 7 | C | A |
| 8 | C | B |
| 9 | C | C
我们使用Azure AD B2C作为我们项目的身份验证提供者。我们在AD B2C中缺少的一个功能是在多次无效登录尝试时锁定帐户。似乎有一种算法可以在一段时间内暂时阻止登录请求,但在此时间之后将允许再次登录。
而且,根据文档:“通过使用各种信号,Azure AD B2C分析请求的完整性。Azure AD B2C旨在智能地将目标用户与黑客和僵尸网络区分开来。Azure AD B2C提供了一种复杂的策略,可以根据输入的密码锁定帐户,以防发生攻击。”
参考
帐户将如何被锁定?如何测试它是否真的会发生呢?
我目前在python项目中使用mysql.connector,在用户输入他们的信息后,执行以下查询:
"SELECT first, last, email, {} FROM {} WHERE {} <= {} AND ispaired IS NULL".format(key, db, class_data[key], key)
如果在两个线程中并发执行此查询,并在两个线程中返回相同的行,则会造成问题。我想知道是否有一种方法可以防止SELECT mysql查询并发执行,或者这是否已经是mysql.connector的默认行为?有关其他信息,所有mysql.connector
我有两个函数可以从一个名为tree_elements的表中创建一个虚拟路径名。表的任何更新都会调用函数路径(id,language)。表的更新有时会导致死锁,并显示错误消息(示例):
select path(621163,"de")
Deadlock found when trying to get lock; try restarting transaction
我不明白为什么会有任何锁定。函数只使用selects,不使用update,不使用insert,不使用delete。我怎样才能避免这种现象?
以下是我的函数:
mysql> show create functi
在以下几个方面是否有任何区别:
INSERT DELAYED INTO tableA SET val='1'
和
INSERT LOW_PRIORITY INTO tableA SET val='1'
两者都受到的支持。
还有一个
这一节说,延迟是计划在未来的释放删除。
延迟插入和替换在MySQL 5.6中被废弃。在MySQL 5.7中,不支持延迟。服务器识别但忽略延迟关键字,将插入处理为非延迟插入,并生成ER_WARN_LEGACY_SYNTAX_CONVERTED警告(“不再支持插入延迟”)。语句被转换为插入“)。延迟关键字计划在以后的发行版中删除。
我正在使用Rails 3.1和MySQL 5.1设计一个类似web应用程序的拍卖。用户将有帐户余额,因此,重要的是,有人不出价拍卖项目,如果他没有足够的资金。
显然,我会把拍卖的“中奖”打包成一笔交易,这样的话:
交易1:
ActiveRecord::Base.transaction do
a = Account.where(:id=>session[:user_id]).first
# now comes a long part of code with various calculations and other table updates, i.e. time pa