[
https://issues.apache.org/jira/browse/DELTASPIKE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13806113#comment-13806113
]
John D. Ament commented on DELTASPIKE-420:
------------------------------------------
I'm thinking about the use case and I'm not sure it makes sense. for something
like transaction support, I think this is something the data module would need
to understand, for example updating a record generally requires a transaction.
It shouldn't be up to a given repository to determine whether or not it needs a
repository, transaction management should happen well below it. I think if
transaction support is needed, the data module should handle that internally.
With that said, I can think of other use cases for interceptor support in
general partial bean usage, where the interceptor logic is not related to what
the method is doing, but some other general business use case (for example,
only allowing this method call to be done if the principal is not null and not
anonymous.).
> Transactional repositories
> --------------------------
>
> Key: DELTASPIKE-420
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-420
> Project: DeltaSpike
> Issue Type: New Feature
> Components: Data-Module
> Affects Versions: 0.5
> Reporter: Harald Wellmann
> Assignee: Thomas Hug
>
> It's nice to get semi-automatic repositories from DeltaSpike Data, but these
> repositories would be even more fun if they were transactional, not
> necessarily by default, but at least by simple configuration.
> Possible approaches:
> 1) Add @Transactional to an abstract repository class, i.e.
> javax.transaction.Transactional in Java EE 7, or
> org.apache.deltaspike.jpa.api.transaction.Transactional otherwise.
> Currently, this does not work due to DELTASPIKE-419.
> 2) Make it easy to override the @Repository binding or the query handler, to
> add transactional behaviour.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
