A general question, how do you all handle opening ...

# exposed

[maxmello]

A general question, how do you all handle opening transactions? For example, do you
• open a new transaction when an endpoint is called, wrap the whole endpoint implementation in newSuspendedTransaction { ... } , and that’s it?
• have all your opening of transaction blocks in the DAO layer or “close” to the models, hidden from the point of view of the endpoint logic? The problem here is that sometimes when dealing with Entity instances, you pass it down to some application logic and then realize you actually need an active transaction to get access to the properties of the entity. Since I don’t want explicit control of transaction rollback etc. in most cases, it feels unnecessary to try to be very fine-grained with it. Some other libraries like Ebean won’t require the user to open transactions at all, except they want to change and rollback multiple entities at once.

[Richard Romanowski]

We have all transactions in the repository implementations. So, "hidden from the pov of the endpoint" What are specific properties you need from the active transaction that you want to bring the transaction scope closer to the endpoint?

[maxmello]

I guess it all depends on how strict the layers of the application are divided. My project is rather small so I would call a query from an EntityClass instance and get Entity instances in return (these would then ‘leak’ into the endpoint implementation), and then if I would want to access a value of a reference object (like myEntity.parent.id) I would still need to be inside a transaction for that to work. So I assume the response type from your repository layer would then be some data class / DTO / database-agnostic model already?