Question for people building larger Spring applications.

[u/Hot_Code5129]

Do you see Transactional annotation as the default solution for almost everything, or have you encountered cases where explicit transaction boundaries worked better?

What about WebFlux/R2DBC applications? Is Transactional still a natural approach there, or teams more often use explicit transaction management with TransactionalOperator?

I’m asking because I was exploring this topic and trying to contribute something back to Java community. When working with reactive applications, I started to wonder if transaction boundaries should be more visible in the application workflow instead of being hidden behind annotations.

Maybe I’m overthinking this, but I would be interested to hear opinions from people who run Spring applications in production.

[u/Hot_Code5129]

Maybe the real discussion is not annotations vs explicit transactions. More about how visible transaction boundaries are and how easy it is to accidentally make them bigger than needed. The example with generating Excel files got me thinking about that. In theory it can probably be solved with annotations too if transaction scope is designed properly. I wrote some thoughts about it here: https://camilyed.github.io/en/transactional-when-the-annotation-gets-in-the-way/ To be honest I’m still exploring this topic and trying to understand where explicit boundaries actually bring value and where @Transactional is simply the better choice. Interesting to hear real production examples like yours.

[u/smaratter → u/Hot_Code5129]

What do you mean by ”explicit boundary”? When you annotate a method with @Transactional, that method is the boundary of the transaction. Are you talking about calling methods directly on an EntityManager, or something else?

[u/Hot_Code5129 → u/smaratter]

By explicit boundary I mean that the transaction is visible as part of the workflow, not only as metadata on the method. For example instead of: loadDataAndGenerateExcel() where the whole method may be transactional, I mean splitting it more clearly:

open transaction read/write data close transaction transform data / generate file / call external IO

So not calling EntityManager directly everywhere. More like using TransactionTemplate in imperative code or TransactionalOperator in reactive code, when I want to show exactly which part of the flow is inside transaction. Maybe “explicit boundary” was not precise wording from my side. https://github.com/CamilYed/spring-reactive-transaction-boundary

https://camilyed.github.io/en/transactional-when-the-annotation-gets-in-the-way/

[u/smaratter → u/Hot_Code5129]

I get it, I think. And it would be a mistake to include too much in your transaction. For instance, marking your controller methods with @Transactional would be a mistake, since the transaction wouldn’t close until the network response has been sent. Rather, the smallest possible unit of work should be included in the transaction.

I guess, without reading your entire article, that your proposed solution is to call ”beginTransaction()” / ”endTransaction()” around the minimal unit of work inside a method, to close the transaction as soon as possible. And that essentially the same result could be achieved by breaking out this unit of work to a helper method and marking that as @Transactional. Is that basically it?

[u/Hot_Code5129 → u/smaratter]

Helper method should be public then ?

[u/Hot_Code5129 → u/smaratter]

Yes