AUTO-CONFIGURATION · CONDITIONS · OWNERSHIP
JDBC activation can connect Exposed to a Spring DataSource and supply one specifically named transaction manager. R2DBC activation is intentionally thinner: the application still owns the pool, R2dbcDatabase, transaction scope, and shutdown.
START WITH OWNERSHIP
DataSource → EntityManagerFactory → JpaTransactionManager → JPA repository proxy
Spring Boot can assemble a familiar, integrated persistence path around the JPA provider.
Provider state, dirty checking, and transaction interception become part of the programming model.
JDBC: DataSource → Database.connect → named manager · R2DBC: mapping + repository factory
SQL, database objects, and coroutine transaction boundaries remain visible in application design.
R2DBC infrastructure and multi-call atomicity are application responsibilities, not inferred defaults.
SOURCE ARCHITECTURE
The two modules share repository discovery and mapping concepts, but they do not own the same infrastructure. Open either source diagram to inspect its full resolution.
CONDITION LAB
Each scenario separates what Spring evaluates from what the application must still provide. The selected card drives both the condition/result ledger and the sequence diagram.
EntityClass on classpathThe auto-configuration class is eligible.
DataSource bean availableThe named transaction manager method can run.
springTransactionManagerThe JDBC auto-configuration does not back off.
ExposedMappingContext createdSpring Data can resolve Exposed entities.
Database.connect(DataSource) invokedExposed JDBC is attached to the application DataSource.
Repository proxies use springTransactionManager by default.
EntityClass on classpathR2DBC mapping auto-configuration is eligible.
The thin auto-configuration may create one.
Pool and R2dbcDatabase are outside this auto-configuration.
ExposedMappingContext createdEntity metadata can be resolved.
R2dbcDatabase remains application-ownedConstruction and close hooks stay explicit.
No reactive Spring manager is contributed.
Both repository registrars can run.
The second mapping contribution observes the first.
The application prevents ambiguous interface discovery.
R2DBC backs off when the JDBC-side bean already exists.
Its DataSource and bean-name conditions still apply.
The shared mapping context does not imply shared transactions.
DataSource bean availableJDBC integration remains eligible.
The application chooses its bean name.
transactionManagerRef matchesThe JDBC extension copies the exact name into the factory bean definition.
Repository wiring follows the configured reference.
Generated repository proxies use the application bean.
A typo is a startup/wiring defect, not a fallback signal.
EntityClass on classpathThe R2DBC auto-configuration is evaluated.
@ConditionalOnMissingBean does not match.
No duplicate mapping context is created.
Its entity-resolution behavior becomes authoritative.
Interfaces may still be discovered.
The integration does not create one.
R2dbcDatabaseRepository execution has no database target.
Metadata success does not prove runtime readiness.
The first real call exposes the missing application-owned objects.
There is no resource lifecycle to observe or close.
EntityClass absentThe class-level condition rejects both auto-configurations.
DataSource cannot unlock configurationBean conditions are never reached after the class condition fails.
The auto-configuration class is not active.
Manager method conditions are not evaluated.
Inspect the classpath rather than bean names first.
CALL → EVALUATE → RESULT
The DataSource exists and the default manager name is free, so the JDBC integration can contribute its complete bean set.
Spring Boot contributes; application owns DataSourceRepository discovery and mapping activate, but database infrastructure and transaction composition remain explicit application code.
Application owns pool, database, and coroutine scopeThe modules can coexist with one mapping context, but their database objects and transaction boundaries remain separate.
Shared metadata; split execution ownershipThe repository configuration extension treats the manager reference as an exact bean name and passes it to the JDBC factory bean.
Application owns manager selectionR2DBC mapping auto-configuration deliberately backs off when the application already supplies ExposedMappingContext.
Application owns mapping customizationA discovered repository and mapping context are not sufficient. The application must construct the pool and R2dbcDatabase before database work.
Application failed to satisfy its infrastructure boundaryThe outer classpath guard fails, so neither mapping nor JDBC manager contributions are considered.
Dependency graph controls activationOWNERSHIP
| Concern | JDBC path | R2DBC path | Operational consequence |
|---|---|---|---|
| Repository discovery | @EnableExposedJdbcRepositories | @EnableExposedR2dbcRepositories | The application chooses package boundaries in both paths. |
| Mapping context | Created when EntityClass is present | Created only when missing | A custom ExposedMappingContext wins on the R2DBC path. |
| Database object | Database.connect(DataSource) during manager creation | Application creates R2dbcDatabase | R2DBC startup and shutdown remain explicit. |
| Transaction manager | Creates bean named springTransactionManager only when that name is missing | No ReactiveTransactionManager contribution | JDBC proxy wiring is name-sensitive; R2DBC uses Exposed coroutine transactions. |
| Multi-call atomicity | Spring service transaction can group calls | Wrap calls in one suspendTransaction | Repository discovery does not define the business transaction boundary. |
CONFIGURATION RECIPES
| Intent | Application supplies | Enable/wire | Verify |
|---|---|---|---|
| Default JDBC | DataSource | @EnableExposedJdbcRepositories | Bean springTransactionManager exists and rollback spans two repository calls. |
| Custom JDBC manager | Named PlatformTransactionManager | transactionManagerRef = "ordersTransactionManager" | Generated repository definition points to that exact name. |
| Coroutine R2DBC | ConnectionPool, R2dbcDatabase, lifecycle | @EnableExposedR2dbcRepositories | One explicit suspendTransaction owns related operations. |
| JDBC + R2DBC | Both infrastructure sets | Separate repository packages | Exactly one mapping context and unambiguous repository interfaces. |
FAILURE DIAGNOSTICS
| Symptom | Likely boundary | Inspect | Correction |
|---|---|---|---|
| No Exposed beans | EntityClass absent | Classpath and condition report | Add the matching Exposed DAO/core dependency or remove the integration. |
| JDBC repository cannot find a manager | Name mismatch | transactionManagerRef and bean names | Provide the exact referenced name or use the default name. |
| R2DBC repository starts but database access fails | Infrastructure not constructed | Pool and R2dbcDatabase initialization | Create, register, and close application-owned infrastructure. |
| Two calls commit independently | Boundary placed at repository methods | Service call graph | Move related operations into one Spring transaction or one suspendTransaction. |
| Unexpected mapping behavior | Custom context backs off auto-configuration | ExposedMappingContext beans | Keep one intentional context and test entity resolution. |
DECISION GUIDE
| Decision | Prefer JDBC integration when… | Prefer R2DBC integration when… | Do not assume |
|---|---|---|---|
| Execution model | The request path is blocking and Spring transaction interception is desirable. | The complete path is coroutine/non-blocking and explicit suspension is desirable. | The web framework name alone decides the driver model. |
| Infrastructure | A Spring-managed DataSource is already the stable boundary. | The application can own pool creation, R2dbcDatabase, readiness, and shutdown. | R2DBC auto-configuration creates those objects. |
| Transaction composition | Several repositories must join a service transaction. | Related operations can be expressed in one explicit coroutine transaction. | An enable annotation creates business atomicity. |
| Customization | A named manager can be wired and tested explicitly. | Explicit factories and database objects are acceptable application code. | A declared but unused annotation attribute changes runtime behavior. |
TRACEABLE CLAIMS
| Claim | Evidence files |
|---|---|
| JDBC activation is guarded by EntityClass and contributes mapping plus a conditionally named manager. |
Verification
Exposed
|
| The JDBC manager path connects Exposed to the application DataSource. |
Verification
Exposed
|
| JDBC repository discovery imports the registrar and JDBC auto-configuration. |
Verification
Exposed
|
| The JDBC extension passes transactionManagerRef to generated repository factory beans. |
Verification
Exposed
|
| JDBC repositories participate through Spring Data transactional factory support. |
Verification
Simple
|
| R2DBC auto-configuration contributes only a missing mapping context after the JDBC phase. |
Verification
Simple
|
| R2DBC repository discovery is explicit through its enable annotation and registrar. |
Verification
Abstract
|
| The R2DBC extension admits suspend and Flow repository methods but does not consume transactionManagerRef. |
Verification
Declared
|
| R2DBC repositories use plain factory support and Exposed suspend transactions rather than Spring transaction interception. |
Verification
Simple
|
| The bilingual manual records the JDBC/R2DBC infrastructure and transaction ownership boundary. |
Source
spring-and-ktor.md
Verification
spring-and-ktor.md
|