In a reactive pipeline, blocking operations must be isolated from the main event loop to prevent thread starvation. `Mono.fromCallable()` (or `Flux.fromIterable`) wraps the blocking call, and subscribing it on a separate bounded elastic scheduler (e.g., `Schedulers.boundedElastic()`) confines its impact, preserving the responsiveness of the overall reactive system. This is a practical migration step before a full move to R2DBC.

While the native query itself fetches the root `Order` entities, any subsequent access to their lazy-loaded associations (e.g., `order.getLineItems()`) will trigger individual SELECT statements for each order. This classic N+1 problem can lead to hundreds of unnecessary database round-trips, severely degrading performance. The choice of native query vs JPQL is secondary to this fundamental eager/lazy fetching concern.

In Spring’s proxy-based AOP, transactional semantics are determined at the proxy boundary. When the outer method’s proxy starts a new transaction (due to REQUIRES_NEW), all code executed within that method’s thread boundary—including calls to other internal methods, even in other beans—shares that same transaction context. The inner `@Transactional` annotation’s propagation setting is not consulted because the call does not go through the inner bean’s proxy.

This design isolates the two resources. The main `@Transactional` ensures all-or-nothing persistence for the database batch. Wrapping the queue operation in a separate `TransactionTemplate` with `PROPAGATION_REQUIRES_NEW` creates a distinct, short-lived transaction that commits independently. If the queue send fails, only its new transaction is rolled back, leaving the main database transaction unaffected. This achieves the required semantics.

Spring Boot’s auto-configuration is designed to back off when it detects a user-provided bean of the same type. By defining a `@Bean` of type `DataSource`, you take full control of its instantiation and configuration while still benefiting from the rest of Spring Boot’s auto-configuration (e.g., for JPA, transaction management). This is the standard, explicit, and most maintainable method for customizing specific infrastructure components.

Optimistic locking is working as intended by preventing stale data updates. The correct pattern is to catch the `OptimisticLockingFailureException` and retry the transaction. In the retry loop, the entity is freshly loaded (with the latest version and background job changes), the user’s specific edits are reapplied to this fresh state, and the update is attempted again. This ensures no data is silently overwritten. Changing the version type or removing locking does not solve the business logic conflict.

The Open Session/EntityManager in View pattern binds a persistence context to the entire HTTP request lifecycle. While convenient for lazy loading in views (e.g., JSPs), in a stateless REST API it is an anti-pattern. It holds database connections open for much longer than necessary—often while waiting for network I/O or JSON serialization—severely limiting connection pool throughput and scalability. Best practice is to disable it (`spring.jpa.open-in-view=false`) and fetch all required data explicitly within transactional service layers.

For large-scale, set-based operations, the most efficient tool is often direct SQL. Spring’s `JdbcTemplate` provides a clean, lightweight abstraction over JDBC for executing a single, optimized SQL UPDATE statement. This leverages the database’s own processing power, minimizes network round-trips, and avoids the overhead of the JPA persistence context, object hydration, and dirty checking. It is the standard choice for performant bulk updates.

Hibernate’s built-in Multi-Tenancy feature, specifically the `CurrentTenantIdentifierResolver` combined with the DISCRIMINATOR (or SCHEMA) strategy, is the most robust and transparent solution. It automatically injects the tenant discriminator into all SQL statements at the session level. This is superior to manual filters or query modifications because it is enforced at the lowest level, is harder to bypass accidentally, and works seamlessly for all CRUD operations and associations.

In a reactive pipeline, blocking operations must be isolated from the main event loop to prevent thread starvation. `Mono.fromCallable()` (or `Flux.fromIterable`) wraps the blocking call, and subscribing it on a separate bounded elastic scheduler (e.g., `Schedulers.boundedElastic()`) confines its impact, preserving the responsiveness of the overall reactive system. This is a practical migration step before a full move to R2DBC.0