You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2008/04/16 18:37:15 UTC

Transaction Decorator Q

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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: Transaction Decorator Q

Posted by Howard Lewis Ship <hl...@gmail.com>.
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
<ig...@gmail.com> 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 <hl...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
>  > For additional commands, e-mail: dev-help@tapestry.apache.org
>  >
>  >
>
>
>  --
>  Best regards,
>
>  Igor Drobiazko
>



-- 
Howard M. Lewis Ship

Creator Apache Tapestry and Apache HiveMind

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org


Re: Transaction Decorator Q

Posted by Igor Drobiazko <ig...@gmail.com>.
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 <hl...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>


-- 
Best regards,

Igor Drobiazko