-
From: Tony Nelson
To: Tapestry users
Sent: Monday, May 05, 2014 6:43 PM
Subject: RE: @CommitAfter for GenericDao
The problem we ran into was explicitly what I documented in my original
e-mail. In our Spring based implementation all of our @Transactional
annotations we in our "
ession into
> a page class, that definitely belongs in the DAO layer, but a simple
> annotation the demarks a transaction doesn't feel out of place to me in a
> page class.
>
>> -Original Message-
>> From: John [mailto:j...@quivinco.com]
>> Sent: Mon
that definitely belongs in the DAO layer, but a simple annotation the
demarks a transaction doesn't feel out of place to me in a page class.
> -Original Message-
> From: John [mailto:j...@quivinco.com]
> Sent: Monday, May 05, 2014 1:10 PM
> To: Tapestry users
> Subje
ril 30, 2014 9:59 PM
Subject: RE: @CommitAfter for GenericDao
From my experience, you really don't want to put CommitAfter on a generic
method like that.
It really doesn't do what you expect in code like this:
void saveSomeData(List widgets) {
for (Widget w: widgets) {
For the record, I agree with what Tony has said. It's usually better to
@CommitAfter on a page action or on a service rather than a low level DAO.
That being said, I think your problem is annotating the interface instead
of the concrete class. Prior to recent 5.4 builds, annotations were not
copie
From my experience, you really don't want to put CommitAfter on a generic
method like that.
It really doesn't do what you expect in code like this:
void saveSomeData(List widgets) {
for (Widget w: widgets) {
widgetDao.saveWidget(widget);
}
}
In that case, assuming saveWidget is annotate
