Extensible transaction definition

[mp911de]

We now expose a Connection.beginTransaction method accepting a TransactionDefinition that can report various transaction attributes. Drivers can choose to provide a vendor-specific extension to specify attributes that apply to their database.

Transaction attributes are optional and expected to be set when starting a transaction when one or more attribute is configured. The callback mechanism allows for a simplified extension model so a library can provide a generic TransactionDefinition implementation that is configured with attributes required for a database without the need to depend on vendor-specific classes.

---

Todo:

• Discuss the proposal
• Documentation

[elefeint]

Is the expected use for a custom driver with unique transaction requirements to create our own version of TransactionDefinition, and not to reuse IsolationLevel?

[elefeint]

s/sql/name

[mp911de]

I'm not exactly sure about this. From the perspective of how one works with a driver, they basically don't want to touch driver-specific API in their client library. So a client library would provide a TransactionDefinition instance backed by the way how it's configured (e.g. HashMap, real pojo, proxy, something else).

From a driver perspective, it could make sense to provide a TransactionDefinition to outline its capabilities (e.g. SqlServerTransactionDefinition.builder().transactionName(…).isolationLevel(SNAPSHOT).timeout(…).build()). I'm not quite sure how much these would be used if one works with a client library. When working directly with R2DBC SPI, the driver-provided implementation would make sense. On the other side, we recommend not touching the SPI directly.

[mp911de]

The revised proposal changes are now available in this PR. The API surface is reduced to a callback interface for TransactionDefinition along with the specification enhancements.