How to get transactional a repository ?

[nicolasduminil]

Hello,
I want to use the Panache's repository pattern. But extending the PanacheRepository doesn't provide transactional operations. For example, the following repository:

@ApplicationScoped
public class BookRepository implements PanacheRepository<Book> {}

won't provide me with a transactional persist() operation. Accordingly, I have to override all the required write only methods in PanacheRepository in order to add @Transactional to them. And there are a lot of them. How could I get transactional write only operations from the PanacheRepository while avoiding having to override all these methods ?

Many thanks in advance.

Nicolas

[turing85]

Hi @nicolasduminil !
Questions should be asked in zulip, on Stackoverflow or on the google mailing list.

To the topic at hand: I do not fully understand what the use-case is. If we have multiple calls that we want to wrap in a transaction, we cann annotate the method in which those calls happen with @Transactional. If we only have a single call, an explicit transaction is not necessary, the database will run each operation in an implicit transaction, if none exists. The guide clearly states that all methods modifying the database must be run in a transaction, the most common way is to add @Transactional to the method in which the call to, e.g. bookRepository.persist(...) happens.

Could you elaborate (in zulip or on stackoverlfow) what exactly the use case is?

[nicolasduminil]

"I do not fully understand ..." I confirm that you don't understand :-). And thank you very much for the link to the guide !

[turing85]

Well... care to explain then?

[yrodiere]

Hi,

I converted this into a Discussion, which should be used for questions as explained by @turing85 .

Regarding your question, I don't know if there is a way to make repositories transactional. I suppose you already tried adding @Transactional directory on your BookRepository class (at the class level, not at the method level) and it didn't affect PanacheRepository methods?

In any case, the way this is usually done is to annotate the methods that call the repository as @Transactional. You would put the @Transactional annotation:

• on your Rest endpoint methods, or even on your Rest endpoint class
• OR, if you have a "service" layer between your Rest endpoints and your repositories, on the service methods or the service class.

See also https://quarkus.io/guides/transaction#declarative-approach

[nicolasduminil]

Thanks for your reply. Putting @Transactional at the rest layer wouldn't make sense from the point of view of the separation of the concerns. As a matter of fact, mixing rest and transactions is a poor design. The same applies to services as well. Accordingly, the only place where it would make sense to annotate with @Transactional is the repository layer. But in this case one needs to override all the write operations (persist, update, delete, in all their flavors) which might be fastidious and repetitive.

[yrodiere]

As a matter of fact, mixing rest and transactions is a poor design

This at least is a common enough idea, though far from being shared by everyone. Just ask @gavinking .

But regardless, without arguing with this idea: people advocating for this generally also advocate for an intermediate layer between your rest layer and your repository later: the service layer. That's where you implement "business" code. And most people want their "business" code to be transactional; if not through database transactions, at least in effect (see below).

mixing rest and transactions is a poor design. The same applies to services as well

Sure you can avoid transactions in the service layer. And then a service calling multiple (transactional) repository methods would not itself be transactional, requiring additional measures to handle cases like "my second repository call failed and I didn't get to run the third one, but the first one was committed". Compensating transactions in SAGA are an example of such additional measures.

Anyway, I won't argue more than this. I'm not an expert in application architecture, and there are too many different views on it for this discussion to matter. There are people advocating for no DB transaction and SAGA patterns everywhere, though I'm not sure there are many who say this is the way to go for every application.

Bottom line, from my point of view: you're entitled to your opinions, but at the very least I wouldn't present putting @Transactional in the repository layer as "the" best practice. It's one possible use case, no more.

But in this case one needs to override all the write operations (persist, update, delete, in all their flavors) which might be fastidious and repetitive.

It sure is. It's also rather pointless, because these operations often involve a single SQL statement anyway, and will automatically open a (short-lived, implicit) transaction on the database side. So you would only be making them transactional to make Quarkus happy, with little to no effect in practice. As explained above, your application wouldn't be transactional unless you take additional measures (SAGA, ...).

Anyway, feel free to open an issue if you want @FroMage or another Panache author to add the ability to make all repository operations transactional by default.