Modifying CommitAfter in that way isn't too hard, but what should happen
if an exception is thrown?
e.g.
enter A
change things 1
enter B
change things 2
exit B
change things 3
throw exception
what should be committed?
Op 11-12-2010 21:04, Howard Lewis Ship schreef:
At the very least, I've been thinking of having @CommitAfter determine when
there is a prior @CommitAfter method further up the stack, and not commit in
that case (letting the outermost @CommitAfter perform the overall commit).
On Sat, Dec 11, 2010 at 10:01 AM, Thiago H. de Paula Figueiredo<
thiag...@gmail.com> wrote:
On Sat, 11 Dec 2010 15:12:25 -0200, Christian Köberl<
tapestry.christian.koeb...@gmail.com> wrote:
Currently, there is only the @CommitAfter annotation in
tapestry-hibernate.
This is good for simple use cases but not sufficient for complex cases.
Agreed.
Therefore Spring introduced @Transactional, would this also make sense for
tapestry-hibernate?
I don't think it makes sense to mix tapestry-hibernate and spring-tx. If
you need something that tapestry-hibernate doesn't handle, use spring-tx for
that.
In addition, Tapestry-Hibernate handles Hibernate only. In addition,
@Transactional has many options which tapestry-hibernate doesn't.
I'd like to see (maybe even write) a transaction manager package built on
Tapestry-IoC and using the EJB 3 annotations, with some way to support other
annotations too (including @CommitAfter and Spring's @Transactional.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
