On Fri, 23 Aug 2013 10:45:27 -0300, Martin Kersten
<martin.kersten...@gmail.com> wrote:
@Dimitry
But using this annotation would introduce a good chance that later in
your project you introduce bugs this way. So I would consider
@CommitAfter to be a harmful feature. The problem with this transaction
behavior it introduces bugs that might happen in so rare circumstances
that you always have no
chance to reproduce or spot it during debug/testing sessions.
I disagree. @CommitAfter never claimed to implement nested transactions,
so, if someone expects it with @CommitAfter, they're wrong, not
@CommitAfter. I agree that its documentation should be more explicit.
Is there a reason why there is no @Transactional annotation dealing with
this issue like the JPA version does? The link I mentioned earlier
provided such implementation. Would be create if Tapestry 5.4 might ship
along with this. In the end I would only need this behavior that if a
transaction is
present the 'inner transaction' would be ignored and only the outter
transaction remains handled. So if transaction exists, do nothing.
Because implementing full transaction support, like Spring and EJB do, is
a very complex to do. Have you ever taken a look at spring-tx code? I did.
It's quite large. Tapestry-IoC never promised to implement a full
transaction manager. Just tapestry-hibernate and tapestry-jpa that provide
simple transaction management because both Hibernate and JPA require
changes to the database to be done inside a transaction.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
