将 Stream 包装到 Flux 时的事务处理

Question

当手动将作为查询结果从 spring 数据 jpa 接收到的Stream包装成Flux时，我真的很难理解背后发生了什么。

考虑以下：

实体：

@NoArgsConstructor
@AllArgsConstructor
@Data
@Entity
public class TestEntity {
    @Id
    private Integer a;
    private Integer b;
}

存储库：

public interface TestEntityRepository extends JpaRepository<TestEntity, Integer> {
    Stream<TestEntity> findByBBetween(int b1, int b2);
}

简单的测试代码：

@Test
@SneakyThrows
@Transactional
public void dbStreamToFluxTest() {
    testEntityRepository.save(new TestEntity(2, 6));
    testEntityRepository.save(new TestEntity(3, 8));
    testEntityRepository.save(new TestEntity(4, 10));

    testEntityFlux(testEntityStream()).subscribe(System.out::println);
    testEntityFlux().subscribe(System.out::println);
    Thread.sleep(200);
}

private Flux<TestEntity> testEntityFlux() {
    return fromStream(this::testEntityStream);
}

private Flux<TestEntity> testEntityFlux(Stream<TestEntity> testEntityStream) {
    return fromStream(() -> testEntityStream);
}

private Stream<TestEntity> testEntityStream() {
    return testEntityRepository.findByBBetween(1, 9);
}

static <T> Flux<T> fromStream(final Supplier<Stream<? extends T>> streamSupplier) {
    return Flux
            .defer(() -> Flux.fromStream(streamSupplier))
            .subscribeOn(Schedulers.elastic());
}

问题：

1. 这是做我所做的正确方法吗，尤其是关于静态fromStream方法？
2. 虽然对testEntityFlux(testEntityStream())的调用符合我的预期，但由于我真的不明白的原因，对testEntityFlux()的调用testEntityFlux()了错误：

reactor.core.Exceptions$ErrorCallbackNotImplemented: org.springframework.dao.InvalidDataAccessApiUsageException: 您正在尝试在没有周围事务的情况下执行流式查询方法，该方法使连接保持打开状态，以便可以实际使用 Stream。 确保使用流的代码使用 @Transactional 或任何其他声明（只读）事务的方式。 引起：org.springframework.dao.InvalidDataAccessApiUsageException：您正在尝试在没有周围事务的情况下执行流式查询方法，该事务使连接保持打开状态，以便可以实际使用 Stream。 确保使用流的代码使用 @Transactional 或任何其他声明（只读）事务的方式。

...当我忘记@Transactional 时通常会发生什么，而我没有忘记。

编辑

注意：代码灵感来自： https : //github.com/chang-chao/spring-webflux-reactive-jdbc-sample/blob/master/src/main/java/me/changchao/spring/springwebfluxasyncjdbcsample/service/ CityServiceImpl.java反过来又受到https://spring.io/blog/2016/07/20/notes-on-reactive-programming-part-iii-a-simple-http-server-application 的启发。 但是， Mono版本具有相同的“问题”。

编辑 2

使用 optional 的示例，请注意在testEntityMono() testEntityOptional() testEntityMono()替换testEntityOptionalManual()会导致工作代码。 因此，这一切似乎都与 jpa 如何获取数据直接相关：

@SneakyThrows
@Transactional
public void dbOptionalToMonoTest() {
    testEntityRepository.save(new TestEntity(2, 6));
    testEntityRepository.save(new TestEntity(3, 8));
    testEntityRepository.save(new TestEntity(4, 10));

    testEntityMono(testEntityOptional()).subscribe(System.out::println);
    testEntityMono().subscribe(System.out::println);

    Thread.sleep(1200);
}

private Mono<TestEntity> testEntityMono() {
    return fromSingle(() -> testEntityOptional().get());
}

private Mono<TestEntity> testEntityMono(Optional<TestEntity> testEntity) {
    return fromSingle(() -> testEntity.get());
}

private Optional<TestEntity> testEntityOptional() {
    return testEntityRepository.findById(4);
}

@SneakyThrows
private Optional<TestEntity> testEntityOptionalManual() {
    Thread.sleep(1000);
    return Optional.of(new TestEntity(20, 20));
}

static <T> Mono<T> fromSingle(final Supplier<T> tSupplier) {
    return Mono
            .defer(() -> Mono.fromSupplier(tSupplier))
            .subscribeOn(Schedulers.elastic());
}

Answer 1

特尔；博士：

它归结为命令式和反应式编程假设以及Thread亲和性之间的差异。

细节

我们首先需要了解事务管理会发生什么，以了解为什么您的安排以失败告终。

使用@Transactional方法为该方法中的所有代码创建一个事务范围。 返回标量值、 Stream 、类集合类型或void （基本上是非反应类型）的事务方法被认为是命令式事务方法。

在命令式编程中，流坚持其载体Thread 。 代码应该保持在同一个Thread而不是切换线程。 因此，事务管理将事务状态和资源与ThreadLocal存储中的载体Thread相关联。 一旦事务方法中的代码切换线程（例如启动新Thread或使用Thread池），在不同Thread上执行的工作单元就会离开事务范围并可能在其自己的事务中运行。 在最坏的情况下，事务在外部Thread上保持打开状态，因为没有事务管理器监控事务工作单元的进入/退出。

@Transactional方法返回响应式类型（例如Mono或Flux ）受响应式事务管理的约束。 反应式事务管理与命令式事务管理不同，因为事务状态附加到Subscription ，特别是订阅者Context 。 上下文仅适用于反应式类型，不适用于标量类型，因为无法将数据附加到void或String 。

查看代码：

@Test
@Transactional
public void dbStreamToFluxTest() {
    // …
}

我们看到这个方法是一个@Transactional测试方法。 在这里，我们需要考虑两件事：

1. 该方法返回void因此它受制于将事务状态与ThreadLocal相关联的命令式事务管理。

2. 没有对@Test方法的反应式事务支持，因为通常期望从该方法返回Publisher ，并且通过这样做，将无法断言流的结果。

    @Test @Transactional public Publisher<Object> thisDoesNotWork() { return myRepository.findAll(); // Where did my assertions go? }

让我们仔细看看fromStream(…)方法：

static <T> Flux<T> fromStream(final Supplier<Stream<? extends T>> streamSupplier) {
    return Flux
        .defer(() -> Flux.fromStream(streamSupplier))
        .subscribeOn(Schedulers.elastic());
}

该代码接受返回Stream的Supplier 。 接下来，订阅（ subscribe(…) 、 request(…) ）信号被指示在弹性Scheduler器上发生，这有效地切换了创建和使用Stream Thread 。 因此， subscribeOn导致Stream创建（调用findByBBetween(…)发生在不同的Thread比你的运营商Thread 。

删除subscribeOn(…)将解决您的问题。

还有一点可以解释为什么要避免在 JPA 中使用反应式类型。 响应式编程没有很强的Thread亲和性。 Thread切换随时可能发生。 根据您使用生成的Flux以及您设计实体的方式，当实体跨线程传递时，您可能会遇到可见性问题。 理想情况下，响应式上下文中的数据保持不变。 这种方法并不总是符合 JPA 规则。

另一方面是延迟加载。 通过使用来自除载体Thread之外的线程的 JPA 实体，该实体可能无法将其上下文关联回 JPA 事务。 您可以轻松地遇到LazyInitializationException而不会意识到这是为什么，因为Thread切换对您来说可能是不透明的。

建议是：不要将反应类型与 JPA 或任何其他事务资源一起使用。 继续使用 Java 8 Stream 。

Answer 2

存储库返回的 Stream 是惰性的。 当流被终端操作消耗时，它使用到数据库的连接来获取行。

连接绑定到当前事务，当前事务存储在 ThreadLocal 变量中，即绑定到正在执行您的测试方法的线程。

但是流的消费是在一个单独的线程上完成的，属于Reactor的弹性调度器使用的线程池。 因此，您在主线程上创建惰性流，该流绑定了事务，但您在单独的线程上使用流，该线程没有绑定事务。

不要对 JPA 事务和实体使用反应器。 他们不相容。