|
对于最新的稳定版本，请使用 Spring Data Relational 3.4.0！ |
事务性
的方法CrudRepository默认情况下，实例是事务性的。
对于读取作，事务配置readOnlyflag 设置为true.
所有其他 API 都配置了 plain@Transactional注解，以便应用默认事务配置。
有关详细信息，请参阅 Javadoc 中的SimpleJdbcRepository.
如果需要调整存储库中声明的方法之一的事务配置，请在存储库接口中重新声明该方法，如下所示：
interface UserRepository extends CrudRepository<User, Long> {
@Override
@Transactional(timeout = 10)
List<User> findAll();
// Further query method declarations
}上述原因导致findAll()方法以 10 秒的超时运行，并且没有readOnly旗。
更改事务行为的另一种方法是使用通常涵盖多个存储库的 Fade 或服务实现。 其目的是定义非 CRUD作的事务边界。 以下示例演示如何创建此类 Facade：
@Service
public class UserManagementImpl implements UserManagement {
private final UserRepository userRepository;
private final RoleRepository roleRepository;
UserManagementImpl(UserRepository userRepository,
RoleRepository roleRepository) {
this.userRepository = userRepository;
this.roleRepository = roleRepository;
}
@Transactional
public void addRoleToAllUsers(String roleName) {
Role role = roleRepository.findByName(roleName);
for (User user : userRepository.findAll()) {
user.addRole(role);
userRepository.save(user);
}
}前面的示例会导致对addRoleToAllUsers(…)在事务内运行（参与现有事务，如果没有正在运行，则创建一个新事务）。
存储库的事务配置被忽略，因为外部事务配置决定了要使用的实际存储库。
请注意，您必须显式激活<tx:annotation-driven />或使用@EnableTransactionManagement获取基于注释的 Facades 配置。
请注意，前面的示例假定您使用组件扫描。
事务查询方法
要使查询方法具有事务性，请使用@Transactional在您定义的 repository 界面上，如下例所示：
@Transactional(readOnly = true)
interface UserRepository extends CrudRepository<User, Long> {
List<User> findByLastname(String lastname);
@Modifying
@Transactional
@Query("delete from User u where u.active = false")
void deleteInactiveUsers();
}通常，您希望readOnly标志设置为 true，因为大多数查询方法只读取数据。
与此相反，deleteInactiveUsers()使用@Modifying注解并覆盖事务配置。
因此，该方法是使用readOnlyflag 设置为false.
| 强烈建议将查询方法设置为事务性。 这些方法可能会执行多个查询以填充实体。 如果没有公共事务，Spring Data JDBC 会在不同的连接中执行查询。 这可能会给连接池带来过大的压力，甚至可能导致在多个方法请求新连接而保留一个方法时出现死锁。 |
通过将readOnly旗。
但是，这并不能作为检查您不会触发纵查询（尽管某些数据库拒绝INSERT和UPDATE语句）。
相反，readOnly标志作为提示传播到底层 JDBC 驱动程序以实现性能优化。 |
JDBC 锁定
Spring Data JDBC 支持对派生查询方法的锁定。
要在存储库中启用对给定派生查询方法的锁定，请使用@Lock.
type 的 required 值LockMode提供两个值：PESSIMISTIC_READ这保证了您正在读取的数据不会被修改，并且PESSIMISTIC_WRITE它获取一个锁来修改数据。
某些数据库不进行这种区分。
在这种情况下，两种模式都等效于PESSIMISTIC_WRITE.
interface UserRepository extends CrudRepository<User, Long> {
@Lock(LockMode.PESSIMISTIC_READ)
List<User> findByLastname(String lastname);
}如您在上面看到的，该方法findByLastname(String lastname)将使用悲观读锁执行。
如果将数据库与 MySQL Dialect 一起使用，则将导致例如以下查询：
Select * from user u where u.lastname = lastname LOCK IN SHARE MODE