Question - Best practices for extending R2dbcTransactionManager?

[dzou]

Hey there,

I'm interested in extending the R2dbcTransactionManager for Cloud Spanner with our Spring Data R2DBC integration. For example, like overriding the prepareTransactionalConnection(..) to allow it to create custom transactions for Spanner.

I was wondering if you could share some best practices for how to best do this for users:

• Should we put this in our project with the Spring Data R2DBC dialect, and then do we ask users to create a @Bean of it in their autoconfiguration so it hooks into Spring data?
• Or should we consider providing our own autoconfiguration and a starter dependency so it's injected automatically?

Many thanks for your guidance.

[mp911de]

Subclassing the transaction manager is the way to go. With Spring Framework, @Transactional(label =…) was introduced to allow labeling transactional methods with further details. Labels can be obtained through TransactionAttribute.getLabels(), accessible from R2dbcTransactionManager.prepareTransactionalConnection(…).

Once R2DBC 0.9 is fully available, we should reconsider the prepareTransactionalConnection and Connection.begin() arrangement in terms of extensible transaction definitions.

Right now, prepareTransactionalConnection implements what the extended Connection.begin(TransactionDefinition) does in terms of setting read only, transaction isolation, and auto-commit flags.

I would assume that we introduce another method that assembles the R2DBC TransactionDefinition so that we can shift functionality from prepareTransactionalConnection into extensible transaction definitions's begin.

[dzou]

@mp911de -- Thanks for the great help!

Sorry, one more followup -- So would you recommend we put our subclass of the Transaction Manager in the same module as our R2DBC dialect? Or is there another pattern R2DBC libraries use? (i.e. creating a starter dependency with autoconfigurations, etc.)

[mp911de]

I think so.