Clarify transaction boundary recommendation

[seungcheol-kwon]

Hi Spring Data JPA team,

While reading the official documentation on transaction management
(https://github.com/spring-projects/spring-data-jpa/blob/3.4.4/src/main/antora/modules/ROOT/pages/jpa/transactions.adoc),
I noticed that it might give the impression that @Transactional should be placed on the repository layer to define transaction boundaries.

However, in most real-world applications, transaction boundaries are typically defined at the service layer.
This is because the service layer represents the unit of business logic that should execute atomically,
and transaction control is better handled in the service layer for consistency and clarity.

So I’d like to clarify the actual intent of the documentation:
Is it encouraging developers to define @Transactional on the repository layer, or was that example simply meant to demonstrate how to provide default read-only settings?

Currently, it can be misinterpreted as a recommendation to control transactions at the repository level.
If that’s not the intended message, I believe it would be helpful to revise or clarify the documentation to prevent confusion.

Thanks for your great work on the project, and I look forward to your guidance!

[mp911de]

Declaring transaction (unit of work) bounds is a wide field that can easily fill a hour-long discussion. We've decided to keep our docs focused on the repository aspect as that is the the latest point where transaction management should happen.

We generally recommend that you start your transaction much earlier and that repositories participate on your transaction. If you want that only the repository participates in a transaction but not your surrounding calls, then annotating the repository (or fragment) methods is the way to go.

Let me know whether this helps and whether the details stated above help to avoid misinterpretations so we can refine our docs.

[seungcheol-kwon]

Thanks for the helpful explanation!

Based on your feedback, I’ve opened a PR to make the documentation a bit clearer:
#3843

If the proposed change doesn’t quite match your intent, I’m more than happy to revise or discuss it further.