I'm glad you agree. I think KISS for now, we can always add new annotations later with good defaults.
On Wed, Apr 16, 2008 at 11:21 AM, Igor Drobiazko <[EMAIL PROTECTED]> wrote: > 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 > -- Howard M. Lewis Ship Creator Apache Tapestry and Apache HiveMind --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
