What system behavior is expected when using the Repeatable Read isolation level during concurrent updates of a single account by two transactions?

At the Repeatable Read isolation level, a transaction guarantees that all data read at the beginning of the transaction will remain unchanged until its completion. If two transactions attempt to update the same account simultaneously, the behavior will be as follows:

• The first transaction that starts the update and commits the changes will acquire a write lock.
• The second transaction, when attempting to update the same account, will wait for the lock to be released or will receive a lock error (depending on the DBMS and settings).

Thus, Repeatable Read prevents non-repeatable reads and ensures that data read at the start of the transaction will not change, but it does not guarantee the absence of phantom reads. In the context of concurrent updates, this means one transaction will wait or roll back to avoid update conflicts.

Example in Java using Spring and JPA:

@Transactional(isolation = Isolation.REPEATABLE_READ)
public void updateAccount(Long accountId, BigDecimal amount) {
    Account account = accountRepository.findById(accountId).orElseThrow();
    account.setBalance(account.getBalance().add(amount));
    accountRepository.save(account);
}

If two such transactions are started simultaneously, one will wait for the other to finish when updating the same account.