I think this corresponds with the default EJB behavior. The transactions are rolled back on runtime exceptions, but not on application (checked) exceptions. We could use this behaviour as default and add further attributes to the @CommitAfter annotation to override the defaults. Take a look at the attributes rollbackFor and noRollbackFor of the spring annotation @Transactional: http://static.springframework.org/spring/docs/2.0.x/api/org/springframework/transaction/annotation/Transactional.html
On Wed, Apr 16, 2008 at 6:37 PM, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > I'm working on TAPESTRY-2256: add a simple transaction decorator > > https://issues.apache.org/jira/browse/TAPESTRY-2256 > > Igor Drobiazko has provided a patch that I'm using as a head start. > > When I've coded these things in the past, one thing I've done is to > commit the transaction on declared exceptions (non-runtime exceptions > declared in the throws clause) and rollback the transaction on any > other exception. That's where I'm headed with this. How would that > fit into people's apps? > > -- > Howard M. Lewis Ship > > Creator Apache Tapestry and Apache HiveMind > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Best regards, Igor Drobiazko
