Spring中的事务原子性

SQL/Spring中的事务原子性意味着什么,它意味着什么？

我在考虑以下情况.如果我错了,请纠正我:

此代码不正确:

@Transactional
public void voteUp(long fooId) {
    Foo foo = fooMapper.select(fooId); // SELECT * FROM foo WHERE fooId == #{fooId}
    foo.setVotes(foo.getVotes() + 1);
    fooMapper.update(foo); // UPDATE foo SET votes = #{votes} (...) WHERE fooId == #{fooId}
}

即使它的事务处理并不意味着"投票"的值总是会增加1,如果在很多机器/许多线程中同时调用voteUp？如果它是这样的话,那意味着一次只能执行一个事务,导致效率下降(特别是如果voteUp代码在事务中做了更多的东西)？

唯一正确的方法就是这样(？):

/* not necessarily */ @Transactional 
public void voteUp(long fooId) {
    fooMapper.voteUp(fooId); // UPDATE foo SET votes = votes + 1 WHERE fooId == #{fooId}
}

在示例中,我使用myBatis连接到数据库,但我认为如果我使用hibernate或纯SQL语句,问题就会保持不变.

隔离级别确定数据视图在事务中的可靠性.最可靠的隔离级别是可序列化的(这确实会影响数据库的性能),但通常的默认值是read-committed:

在此隔离级别中,基于锁的并发控制DBMS实现保持写锁(在所选数据上获取)直到事务结束,但是一旦执行SELECT操作就会释放读锁(因此不可重复读取现象可以在这种隔离级别发生,如下所述).与上一级别一样,不管理范围锁定.

换句话说,read committed是一个隔离级别,它保证读取时提交任何数据.它只是限制读者看到任何中间的,未提交的,"脏"的读.它没有任何承诺,如果事务重新发出读取,它将找到相同的数据; 数据在读取后可以自由更改.

在第一个示例中,在select和update之间,某些其他进程可以更改计数器的值:选择发生,然后某个其他进程更改计数器的值,然后更新作用于更改的行.

将隔离级别更改为可重复读取应确保第一个示例中的增量正常工作.当然第二个例子是正确的,因为它是一个更好的解决方案.