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 "logic" layer, and it worked well. I started out using @CommitAfter
exactly the same way, until I ran into methods like:
public void saveSomething(Something something) {
// add a bunch of validations
// and maybe a bunch of business rules
// and then updates to other objects
// and then finally
dao.save(something);
// oh and maybe some post processing
}
public void saveAListOfSomethings(List<Something> somethings) {
for (Something something : somethings) { saveSomething(something); }
}
After running into this too many times in our codebase, we made the decision to
remove all @CommitAfter annotation from our logic layer (even wrote a test
case) and push them out to where the actual transaction logically existed. For
us this includes web pages, REST endpoints, and even command line programs.
This has worked very well for us.
I'm also not sure I completely agree with your separation of concerns argument
either. Granted, I would never allow anyone to @Inject Session 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: Monday, May 05, 2014 1:10 PM
> To: Tapestry users
> Subject: Re: @CommitAfter for GenericDao
>
> At the risk of sounding like a fanatic...
>
> I would avoid using @CommitAfter or anything similar to do with
> persistence in page classes, it contravenes the OO "seperation of
> concerns" principle. (For the same reasons @CommitAfter should also not
> be in interface definitions as suggested in the Tapestry docs' because
> it's implementation specific.)
>
> A better place would be a facade layer* between your DAOs and your page
> classes. This might not be justified if you want to keep your
> application architecture minimal, but even so it represents best
> practice and is a great place to code your business logic. Your page
> classes can then focus exclusively on delivery of page content and your
> DAOs on pure data access.
>
> regards,
> John
>
> *http://en.wikipedia.org/wiki/Facade_pattern
> ----- Original Message -----
> From: Tony Nelson
> To: Tapestry users
> Sent: Wednesday, April 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<Widget> widgets) {
> for (Widget w: widgets) {
> widgetDao.saveWidget(widget);
> }
> }
>
> In that case, assuming saveWidget is annotated with @CommitAfter,
> every iteration of the loop will commit separately, which is likely not
> what you want.
>
> The @CommitAfter annotation is much better used in your page classes
> to commit transactions after a logical unit of work is complete.
>
> Tony
>
> > -----Original Message-----
> > From: Eugen [mailto:eugens...@gmail.com]
> > Sent: Wednesday, April 30, 2014 4:48 PM
> > To: Tapestry users
> > Subject: @CommitAfter for GenericDao
> >
> > Hi,
> > I try to use the CommitAfter on a GenericDao, but the method does
> not
> > commit the transaction. Does it exists a worcaround to do that?
> >
> > This is the code:
> >
> > public interface GenericDao<T> {
> > @CommitAfter
> > public void save(T entity);
> > }
> >
> > public abstract class GenericDaoImpl<T> {
> > @Override
> > public void save(T entity) {
> > entityManager.persist(entity);
> > }
> > }
> >
> > public interface UserDao extends GenericDao<User> { }
> >
> > public class UserDaoImpl extends GenericDaoImpl<User> implements
> > UserDao { }
> >
> > and respective advisor in AppModule:
> >
> > @Match("*Dao")
> > public static void adviseTransactions(JpaTransactionAdvisor
> advisor,
> > MethodAdviceReceiver receiver) {
> > advisor.addTransactionCommitAdvice(receiver);
> > }
> >
> > if I place the save() function into the UserDao all works fine.
> >
> > Thanks in advice
> > Eugen
> >
> > -------------------------------------------------------------------
> --
> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> > For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
> Since 1982, Starpoint Solutions has been a trusted source of human
> capital and solutions. We are committed to our clients, employees,
> environment, community and social concerns. We foster an inclusive
> culture based on trust, respect, honesty and solid performance. Learn
> more about Starpoint and our social responsibility at
> http://www.starpoint.com/social_responsibility
>
> This email message from Starpoint Solutions LLC is for the sole use
> of the intended recipient(s) and may contain confidential and
> privileged information. Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient,
> please contact the sender by reply email and destroy all copies of the
> original message. Opinions, conclusions and other information in this
> message that do not relate to the official business of Starpoint
> Solutions shall be understood as neither given nor endorsed by it.
>
> ----------------------------------------------
> T ususcib, -mil uer-usus...@tpetr.aace.rg
> Fr ddtina cmmnd, -mil uer-hlptaesryapch.og
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
Since 1982, Starpoint Solutions has been a trusted source of human capital and
solutions. We are committed to our clients, employees, environment, community
and social concerns. We foster an inclusive culture based on trust, respect,
honesty and solid performance. Learn more about Starpoint and our social
responsibility at http://www.starpoint.com/social_responsibility
This email message from Starpoint Solutions LLC is for the sole use of the
intended recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited. If
you are not the intended recipient, please contact the sender by reply email
and destroy all copies of the original message. Opinions, conclusions and
other information in this message that do not relate to the official business
of Starpoint Solutions shall be understood as neither given nor endorsed by it.
